Skip site navigation (1) Skip section navigation (2)

Re: Review of Writeable CTE Patch

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Marko Tiikkaja <marko(dot)tiikkaja(at)cs(dot)helsinki(dot)fi>, Takahiro Itagaki <itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)jp>, Merlin Moncure <mmoncure(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Review of Writeable CTE Patch
Date: 2010-02-03 16:08:19
Message-ID: 603c8f071002030808s3b36d51cgf8bc7bac6374d07c@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-hackers
On Wed, Feb 3, 2010 at 10:58 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> On Wed, Feb 3, 2010 at 4:09 AM, Marko Tiikkaja
>> <marko(dot)tiikkaja(at)cs(dot)helsinki(dot)fi> wrote:
>>> We have yet to reach a consensus on the name for this feature.  I don't
>>> think we have any really good candidates, but I like "DML WITH" best so far.
>
>> Why can't we complain about the actual SQL statement the user issued?
>> Like, say:
>> INSERT requires RETURNING when used within a referenced CTE
>
> We could probably make that work for error messages, but what about
> documentation?  It's going to be awkward to write something like
> "INSERT/UPDATE/DELETE RETURNING" every time we need to make a general
> statement about the behavior of all three.

The current patch includes a total of 5 lines of text documenting this
new feature (plus one example), so the issue doesn't really arise.

If, as I believe, more documentation is needed, then we may need to
think about how to handle this, but it's hard to speculate without a
bit more context.

...Robert

In response to

Responses

pgsql-hackers by date

Next:From: Tom LaneDate: 2010-02-03 16:09:29
Subject: Re: Recent vendor SSL renegotiation patches break PostgreSQL
Previous:From: Marko TiikkajaDate: 2010-02-03 16:04:57
Subject: Re: Review of Writeable CTE Patch

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group