On Fri, Aug 15, 2014 at 9:54 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Andres Freund <andres@2ndquadrant.com> writes:
>> On 2014-08-14 12:21:38 -0400, Robert Haas wrote:
>>> And what does that actually do? Send back a result-set, or a new
>>> protocol message?
>
>> What I was thinking of was to return "COMMIT X/X" instead of
>> "COMMIT". Since that's only sent when COMMIT WITH (report_commit_lsn ON)
>> was set it won't break clients/libraries that don't need it.
>
> Au contraire: it will break any piece of code that is expecting a COMMIT
> command tag to look like exactly "COMMIT" and not "COMMIT something".
> If you think there isn't any such, a look into libpq should disabuse you
> of that notion. (Admittedly, libpq's instance is only in the protocol-V2
> code paths, but I'm sure that similar code exists elsewhere client-side.)
Well, I remember debating this with you once before, when we were
deciding whether to make SELECT INTO and CREATE TABLE AS return row
counts in the command tag. That change went into 9.0 and, while I
think we may have gotten maybe one complaint about it, on the whole I
believe it went pretty smoothly. If we're going to expose this
information, I believe that exposing it through the command tag is
about an order of magnitude safer than trying to return it through a
new protocol message or a result-set. I *have* seen code that parses
command tags and cares about their exact contents, but I think nearly
all code passes them through as uninterpreted strings. Contrariwise,
there is a whole LOT of code that cares whether PQresultStatus()
returns PGRES_COMMAND_OK vs. PGRES_TUPLES_OK; if we made the latter
happen for some commits, a huge amount of stuff would break. And
adding a new protocol message is a disaster for middleware, but most
if not all of that middleware will happily pass on a revised command
tag without batting an eyelash.
All that having been said, I'm not convinced that we should do this at
all unless we've got a libpq implementation of client-side failover so
that people can actually use this without having to put all of the
logic in their application. But if we are going to do it, the command
tag seems like the least-risky option of those proposed thus far by a
considerable margin.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
