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: Marti Raudsepp <marti(at)juffo(dot)org>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [PATCH] Return command tag 'REPLACE X' for CREATE OR REPLACE statements.
Date: 2010-11-29 00:18:14
Message-ID: AANLkTi=d3F-nkOTHEfe2QNbkgs-nxZSRkGdkw5dSybjL@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sun, Nov 28, 2010 at 11:29 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Marti Raudsepp <marti(at)juffo(dot)org> writes:
>> 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.
>
> This is going to break clients that expect commands to return the same
> command tag as they have in the past.  I doubt that whatever usefulness
> is gained will outweigh the compatibility problems.

You complained about this when we changed the SELECT tag for 9.0 to
include row-counts for CTAS etc. where it hadn't before. Have we
gotten any complaints about that change breaking clients?

I think more expessive command tags are in general a good thing. The
idea that this particular change would be useful primarily for humans
examining the psql output seems a bit weak to me, but I can easily see
it being useful for programs. Right now a program has no reason to
look at this command tag anyway; it'll always be the same.

--
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 Tom Lane 2010-11-29 00:33:01 Re: profiling connection overhead
Previous Message Tom Lane 2010-11-29 00:15:43 Re: profiling connection overhead