Craig Ringer <craig@2ndquadrant.com> writes:
> On 08/08/2014 09:02 AM, Tom Lane wrote:
>> Craig Ringer <craig@2ndquadrant.com> writes:
>>> 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 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.
Right. AFAICS it's mostly irrelevant whether or not the setting can be
changed intrasession; what *is* important is that it not be turned on
if the lowest level(s) of the client software stack can't handle it.
It's not beyond the realm of credibility that there could be
security-grade bugs arising from client software receiving messages it
didn't understand. And what that means is that anything that is
accessible to higher levels of the stack is suspect. We've provided
enough pass-through behaviors that I'm not sure anything in the current
connection options API would be safe.
> AFAIK we don't _have_ a fancy negotiation system in the protocol, with
> back-and-forth exchanges of capabilities information.
Maybe it's time to invent that. It would be positively foolish to
create any such behavior without a protocol version bump anyway.
Although as I said, I don't think embedding knowledge of LSNs at the
protocol level is a good thing to begin with. Is it really necessary that
this information be pushed to the client on every commit, as opposed to
the client asking for it occasionally?
regards, tom lane