Re: Writeable CTEs Desgin Doc on Wiki

On Mon, Aug 16, 2010 at 11:41 PM, Hitoshi Harada <umi(dot)tanuki(at)gmail(dot)com> wrote:
> 2010/8/17 Robert Haas <robertmhaas(at)gmail(dot)com>:
>> On Sun, Aug 15, 2010 at 7:44 AM, Hitoshi Harada <umi(dot)tanuki(at)gmail(dot)com> wrote:
>>> We (Marko, David Fetter and I) discussed on IRC about design of
>>> writeable CTEs. It does and will contain not only syntax but also
>>> miscellaneous specifications, general rules and restrictions. I hope
>>> this will help the patch reviews and stop dangerous design at the
>>> early stage. If you find something wrong, or have request, please
>>> notify.
>>>
>>> http://wiki.postgresql.org/wiki/WriteableCTEs
>>>
>>> We will keep to add details. Any comments are welcome.
>>
>> There are really two separate features here, and it might be worth
>> giving them separate names and separate designs (and separate
>> patches).  Allowing the main query to be an insert, update, or delete
>> seems easier than allowing the toplevel CTEs to contain those
>> constructs, although I might be wrong about that.
>>
>> Under features, what is DCL?  There has been previous talk of allowing
>> WITH (COPY ...) and I am personally of the opinion that it would be
>> nice to be able to do WITH (EXPLAIN ...).  DDL seems like a poor idea.
>
> So, there are three? One for allowing the main query to be an insert,
> update, or delete, one for the main subject of writeable CTE with
> insert, update, delete and one for allowing COPY to return rows. I am
> attracted by such COPY functionality.

Yeah, I'd say there are at least three. Maybe more than three.

> And the first part seems easier to be committed separately. Is it
> possible to get it in by only adding syntax and little parser/planner
> modification, or more executor code?

I'm not sure exactly what is involved, but it seems to me that
breaking large features into moderately-sized, self-contained chunks
tends to drastically shorten the time to commit. Of course, this is
only true if each patch is really an independent feature with
independent utility, but in this case it seems fairly easy to draw a
clean line.

>> P.S. Call me a prude, but your choice of shorthand for
>> insert-update-delete may not be the best.
>
> I think so, too :(. But there's no good expression in my mind. Suggestions?

DML?

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company