Postgres Pro
Downloads
Home   >   mailing lists

Re: [PATCH] Return command tag 'REPLACE X' for CREATE OR REPLACE statements. - Mailing list pgsql-hackers

From Robert Haas
Subject Re: [PATCH] Return command tag 'REPLACE X' for CREATE OR REPLACE statements.
Date
Msg-id AANLkTimUiMiG6HqvQjGWDdOmc2stqf0EYwqAPM+q66=i@mail.gmail.com
Whole thread Raw
In response to Re: [PATCH] Return command tag 'REPLACE X' for CREATE OR REPLACE statements.  (KaiGai Kohei <kaigai@ak.jp.nec.com>)
Responses Re: [PATCH] Return command tag 'REPLACE X' for CREATE OR REPLACE statements.  (Alvaro Herrera <alvherre@commandprompt.com>)
Re: [PATCH] Return command tag 'REPLACE X' for CREATE OR REPLACE statements.  (Marti Raudsepp <marti@juffo.org>)
List pgsql-hackers
Tree view 
2011/1/13 KaiGai Kohei <kaigai@ak.jp.nec.com>:
> I tried to pick up this patch to review.
>
> It seems to me fine, enough simple and works as explained in the
> implementation level, apart from reasonability of this feature.
> (Tom was not 100% agree with this feature 1.5month ago.)

Did you check whether this updated the code for 100% of the object
types where this could apply?

> I'm not certain whether the current regression test should be
> updated, or not. The pg_regress launches psql with -q option,
> so completionTag is always ignored.

Well, I don't see any easy way of regression testing it, then.  Am I
missing something?

Also, I don't really like the way this spreads knowledge of the
completionTag out all over the backend.  I think it would be better to
follow the existing model used by the COPY and COMMIT commands,
whereby the return value indicates what happened and
standard_ProcessUtility() uses that to set the command tag.

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

pgsql-hackers by date:

Previous
From: Magnus Hagander
Date:
Subject: Re: Streaming base backups
Next
From: Magnus Hagander
Date:
Subject: Re: Recovery control functions