Re: [PATCH] Return command tag 'REPLACE X' for CREATE OR REPLACE statements.

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Peter Eisentraut <peter_e(at)gmx(dot)net>, 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-23 02:11:27
Message-ID: AANLkTimZFK1tHdKFw7t4XKhzbAPL=ZCgd7PaCa9octpH@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Jan 17, 2011 at 2:52 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> On Mon, Jan 17, 2011 at 2:25 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>>> On Mon, Jan 17, 2011 at 9:41 AM, Peter Eisentraut <peter_e(at)gmx(dot)net> wrote:
>>>> 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.
>>
>> ROTFL ...
>>
>> There has been some previous banter about reorganizing or reclassifying
>> the various NOTICE messages to make them more useful and/or less noisy;
>> but I don't think we've ever had a really concrete proposal for better
>> behavior.  Maybe it's time to reopen that discussion.
>>
>> I do agree with Peter's underlying point: it would be pretty
>> inconsistent for CREATE OR REPLACE to report this bit of info via
>> command tag when CREATE IF NOT EXISTS is reporting an absolutely
>> equivalent bit of info via elog(NOTICE).
>
> There's a fine line between serious discussion, humor, and outright
> mockery here, and I'm not too sure which one Peter's currently engaged
> in.  I guess the point here for me is that commands tags for SELECT,
> INSERT, UPDATE, and DELETE all return some useful information about
> what actually happened - especially, a row count.  If it's reasonable
> for those commands to return a row count in the command tag, then
> there's no reason why utility commands shouldn't also be allowed to
> return high-level status information as part of the command tag.  On
> the flip side we could just rip out command tags altogether and have
> psql print out the first two words of the input string.
>
> The asymmetry between DROP-IF-EXISTS and CREATE-IF-NOT-EXISTS and the
> proposed CREATE-OR-REPLACE behavior doesn't bother me very much,
> because it's already asymmetric: the first two currently report what
> happened, and the third one currently doesn't.  If you want to propose
> to make all of them consistent, how?  I don't particularly like the
> idea of adding a NOTICE here; we've got too many of those already[1].
> Making DIE report that it didn't do anything via a command tag clearly
> won't work, because you can say "DROP IF EXISTS foo, bar, baz" and the
> answer might not be the same in all three cases, but COR has no such
> issue.

It seems no one wants to put any further effort into this problem. Bummer.

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2011-01-23 02:13:07 Re: auto-sizing wal_buffers
Previous Message Tom Lane 2011-01-23 02:08:22 Re: auto-sizing wal_buffers