On 08/08/2014 09:02 AM, Tom Lane wrote:
> Craig Ringer <craig@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
