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

From KaiGai Kohei
Subject Re: [PATCH] Return command tag 'REPLACE X' for CREATE OR REPLACE statements.
Date
Msg-id 4D2FD287.3000505@ak.jp.nec.com
Whole thread Raw
In response to [PATCH] Return command tag 'REPLACE X' for CREATE OR REPLACE statements.  (Marti Raudsepp <marti@juffo.org>)
Responses Re: [PATCH] Return command tag 'REPLACE X' for CREATE OR REPLACE statements.  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
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.)

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.

Thanks,

(2010/11/29 0:14), Marti Raudsepp wrote:
> Hi list,
> 
> Often enough when developing PostgreSQL views and functions, I have
> pasted the CREATE OR REPLACE commands into the wrong window/shell and
> ran them there without realizing that I'm creating a function in the
> wrong database, instead of replacing. Currently psql does not provide
> any feedback of which action really occured.
> 
> Only after writing this patch I realized that I could instead raise a
> NOTICE, like current IF EXISTS/IF NOT EXISTS clauses do. Is that a
> better way to solve this?
> 
> This patch returns command tag "CREATE X" or "REPLACE X" for
> LANGAUGE/VIEW/RULE/FUNCTION. This is done by passing completionTag to
> from ProcessUtility to more functions, and adding a 'bool *didUpdate'
> argument to some lower-level functions. I'm not sure if passing back
> the status in a bool* is considered good style, but this way all the
> functions look consistent.
> 
> Regards,
> Marti
> 
-- 
KaiGai Kohei <kaigai@ak.jp.nec.com>


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Bug in pg_dump
Next
From: Shigeru HANADA
Date:
Subject: Re: SQL/MED - file_fdw