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

From Tom Lane
Subject Re: [PATCH] Return command tag 'REPLACE X' for CREATE OR REPLACE statements.
Date
Msg-id 9404.1295032039@sss.pgh.pa.us
Whole thread Raw
In response to Re: [PATCH] Return command tag 'REPLACE X' for CREATE OR REPLACE statements.  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: [PATCH] Return command tag 'REPLACE X' for CREATE OR REPLACE statements.  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> On Fri, Jan 14, 2011 at 1:35 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> That 9.0 change was far less invasive than this: it only added a count
>> field to SELECT and CTAS result tags. �Quite aside from the fact that
>> the tag name stayed the same, in the SELECT case it's unlikely anyone
>> would have checked the tag at all rather than just testing for
>> PQresultStatus() == PGRES_TUPLES_OK.

> Yeah, but that one command tag was SELECT.  That's a pretty commonly
> used command.

You're ignoring the point that people would probably use PQresultStatus
in preference to checking the tag at all, when dealing with SELECT.
psql itself is an example --- it never looks at the tag, nor shows it to
the user, in the SELECT case.  That patch only really changed the
exposed behavior for CREATE TABLE AS SELECT / SELECT INTO, neither of
which can be claimed to be hugely popular things for programs to issue.

The other side of the argument that needs to be considered is what the
benefit is.  There was a fairly clear functional gain from reporting
the rowcount for CTAS.  I'm less convinced that sending back REPLACE
is a big benefit worth taking big compatibility risks for.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Simon Riggs
Date:
Subject: Re: LOCK for non-tables
Next
From: Robert Haas
Date:
Subject: Re: LOCK for non-tables