On 29 June 2017 at 10:27, Tom Lane <t...@sss.pgh.pa.us> wrote: > Craig Ringer <cr...@2ndquadrant.com> writes: >> On 29 June 2017 at 03:01, Robert Haas <robertmh...@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.
It does. But I don't see anywhere that extra round trips have been discussed. -- 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
