On 08/08/2014 09:02 AM, Tom Lane wrote: > Craig Ringer <cr...@2ndquadrant.com> writes: >> On 08/08/2014 03:54 AM, Tom Lane wrote: >>> FWIW, I think it's a seriously bad idea to expose LSNs in the protocol >>> at all. What happens five years from now when we switch to some other >>> implementation that doesn't have LSNs? > >> Everyone who's relying on them already via pg_stat_replication, etc, breaks. >> They're _already_ exposed to users. That ship has sailed. > > They're exposed to replication tools, yeah, but embedding them in the > wire protocol would be moving the goalposts a long way past that. As an > example of something that doubtless seemed like a good idea at the time, > consider the business about how an INSERT command completion tag includes > the OID of the inserted row. We're stuck with that obsolete idea > *forever* because it's embedded in the protocol for all clients.
That makes sense. >> Well, I'd prefer to be able to negotiate with the server and establish >> requirements during the protocol handshake. > > Sure, but a GUC is not that. The problem with a GUC for changing > wire-level behavior is that it might be set by code far removed from > the wire, possibly breaking lower code levels that expected different > behavior. The multitude of ways that we offer for setting GUCs is > an active evil in this particular context. I'd value your input and suggestions then. I thought this is what PGC_BACKEND GUCs were for - set them in the startup packet and you can't mess with them afterwards. I can see that the ability of someone to cause that to be set in (e.g.) PGOPTIONS could be a problem though. AFAIK we don't _have_ a fancy negotiation system in the protocol, with back-and-forth exchanges of capabilities information. So is the appropriate thing to do here to set a non-GUC 'options' field in the startup packet? -- Craig Ringer http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
