On Fri, Jan 14, 2011 at 2:07 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> 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.
I would assume they would also use PQresultStatus() when checking
whether CREATE OR REPLACE FUNCTION worked. Even if they were using
PQcmdStatus() for some reason, which seems like an odd thing to do,
there'd be no reason to check for anything beyond "is it empty?". The
idea that there are massive amounts of code out there that are
expecting the command tag to be *exactly* CREATE FUNCTION and will
break if it differs by a byte seems quite improbable. Can you produce
an example of any such code?
> 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.
Asserting that there are "big compatibility risks" doesn't make it so
- you've offered no evidence of that. Even if a handful of people had
complained about that one, I would still felt it was a good change,
but it doesn't seem that there are any at all. I classify this as one
of a dozen or two minor usability enhancements that we make in every
release, and most people don't care, and those who do go "oh, that's
handy". I think before we reject a patch for breaking things, we
ought to be able to identify either some actual application that is
broken by it, or at least some reasonably plausible coding pattern
that would blow up.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
