Craig Ringer <craig@2ndquadrant.com> writes:
> On 29 June 2017 at 03:01, Robert Haas <robertmhaas@gmail.com> wrote:
>> It wouldn't be
>> so bad if unrecognized parameters were just ignored; the client would
>> know from the ServerProtocolVersion (or ParameterStatus) message that
>> server had ignored those options and could respond as it saw fit.
> Yeah. In retrospect it's a pity the key/value pairs don't come with
> some kind of optional/required flag so the client can say "error if
> you don't understand this, it's important" or "I don't care if you
> don't understand this, and I'll notice when you fail to GUC_REPORT it
> back to me". Or some convention like underscore-prefixing for
> optional.
Yeah. Back in the day I helped design the PNG image format, and one
of the better ideas in it was to make a distinction between critical and
noncritical chunks within a PNG file; that was exactly the idea you're
getting at here. I agree with the suggestion to drive this off a
parameter-name-based convention. Having leading underscore indicate
a noncritical parameter sounds fine.
I don't really like any of the ideas that have been mentioned that would
introduce extra network round trips into session startup. It's expensive
enough already. The only thing we seem to be really hurting on is the
ability for the client to add extensions to the original StartupMessage,
and this seems like it can fix that.
regards, tom lane