From: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Marti Raudsepp <marti(at)juffo(dot)org>, KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [PATCH] Return command tag 'REPLACE X' for CREATE OR REPLACE statements. |
Date: | 2011-01-17 19:23:07 |
Message-ID: | 1295292187.12898.6.camel@vanquo.pezone.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On mån, 2011-01-17 at 10:05 -0500, Robert Haas wrote:
> On Mon, Jan 17, 2011 at 9:41 AM, Peter Eisentraut <peter_e(at)gmx(dot)net> wrote:
> > On fre, 2011-01-14 at 18:45 -0500, Robert Haas wrote:
> >> On Fri, Jan 14, 2011 at 3:45 PM, Marti Raudsepp <marti(at)juffo(dot)org>
> >> wrote:
> >> > There's a similar case with CREATE TABLE IF NOT EXISTS, maybe this
> >> is
> >> > worth covering in an updated patch too?
> >> > And if I change that, people might expect the same from DROP X IF
> >> EXISTS too?
> >>
> >> It's far less clear what you'd change those cases to say, and they
> >> already emit a NOTICE, so it seems unnecessary.
> >
> > Maybe instead of the proposed patch, a notice could be added:
> >
> > NOTICE: existing object was replaced
>
> Well, that would eliminate the backward-compatibility hazard, pretty
> much, but it seems noisy. I already find some of these notices to be
> unduly informative.
I'm also anti-NOTICE.
I'm just saying, we propose that CREATE OR REPLACE should return a tag
of CREATE or REPLACE depending on what it did, then DROP IF NOT EXISTS
should also return a tag of DROP or ??? depending on what it did. Since
the latter question was settled by a notice, that would also be the
proper answer for the former.
Perhaps the next thing is that MERGE should return INSERT or UPDATE
depending on the outcome?
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2011-01-17 19:25:44 | Re: [PATCH] Return command tag 'REPLACE X' for CREATE OR REPLACE statements. |
Previous Message | Peter Eisentraut | 2011-01-17 19:18:36 | Re: Determining client_encoding from client locale |