On Fri, Jan 14, 2011 at 12:07 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Alvaro Herrera <alvherre@commandprompt.com> writes:
>> Excerpts from Robert Haas's message of vie ene 14 08:40:07 -0300 2011:
>>> 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.
>
>> Yeah, that looks ugly. However it's already ugly elsewhere: for example
>> see PerformPortalFetch. I am not sure if it should be this patch's
>> responsability to clean that stuff up. (Maybe we should decree that at
>> least this patch shouldn't make the situation worse.)
>
> I thought we were going to reject the patch outright anyway. The
> compatibility consequences of changing command tags are not worth the
> benefit, independently of how ugly the backend-side code may or may
> not be.
My previous response to this criticism was here:
http://archives.postgresql.org/pgsql-hackers/2010-11/msg01899.php
Your response, which seemed at least partially in agreement, is here:
http://archives.postgresql.org/pgsql-hackers/2010-11/msg01901.php
If we're going to reject this patch on backwards-compatibility
grounds, we need to make an argument that the backward-compatibility
hazards are a real concern. So, again, has anyone complained about
the changes we made in this area in 9.0? And under what circumstances
do we foresee someone relying on the command tag of a command that
always returns the same tag? I'm as quick as anyone to bow before a
compelling argument, but I don't think anyone's made such an argument.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
