On Fri, Aug 15, 2014 at 9:54 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Andres Freund <and...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers