From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Alvaro Herrera <alvherre(at)commandprompt(dot)com>, KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com>, 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: | 2011-01-14 19:07:19 |
Message-ID: | 9404.1295032039@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Fri, Jan 14, 2011 at 1:35 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2011-01-14 19:08:24 | Re: LOCK for non-tables |
Previous Message | Simon Riggs | 2011-01-14 19:04:36 | Re: LOCK for non-tables |