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

From: KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com>
To: Marti Raudsepp <marti(at)juffo(dot)org>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [PATCH] Return command tag 'REPLACE X' for CREATE OR REPLACE statements.
Date: 2011-01-14 04:35:19
Message-ID: 4D2FD287.3000505@ak.jp.nec.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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(at)ak(dot)jp(dot)nec(dot)com>

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Shigeru HANADA 2011-01-14 05:20:20 Re: SQL/MED - file_fdw
Previous Message Tom Lane 2011-01-14 04:22:27 Re: Bug in pg_dump