Hi,
On 10/30/24 3:49 PM, Jelte Fennema-Nio wrote:
On Wed, 30 Oct 2024 at 19:04, Jesper Pedersen
<jesper.peder...@comcast.net> wrote:
Having LSN would be nice, but to break all existing implementations, no.
Having to specify with startup parameters how a core message format
looks like sounds like a bad idea to me,
It would really help if you would explain why you think it's a bad
idea to use a startup parameter for that, instead of simply stating
that you think it needs a major protocol version bump.
The point of enabling it through a startup parameter (aka protocol
option) is exactly so it will not break any existing implementations.
If clients request the protocol option (which as the name suggests is
optional), then they are expected to be able to parse it. If they
don't, then they will get the old message format. So no existing
implementation will be broken. If some middleware/proxy gets a request
for a startup option it does not support it can advertise that to the
client using the NegotiateProtocolVersion message. Allowing the client
to continue in a mode where the option is not enabled.
So, not bumping the major protocol version and enabling this feature
through a protocol option actually causes less breakage in practice.
Yes, but it opens up for everybody changing all message formats by
startup parameters.
And, it will be confusing to clean-room implementations: When you have
this startup parameter then you get these message formats, when you have
this startup parameter then you get these message formats -- and what
about combinations ? Like Tatsuo-san stated up-thread.
You are also assuming that all PostgreSQL protocol implementations uses
the Length (Int32) field very strict - so when one developer adds the
startup parameter, but doesn't change the underlying implementation
everything will break.
The protocol format must be 100% clear and well-documented in all cases.
Also regarding the wishlist. I think it's much more likely for any of
those to happen in a minor version bump and/or protocol option than it
is that we'll bump the major protocol version.
I agree that protocol v4 is likely far out unless somebody want to
coordinate the work needed.
P.S. Like I said in another email on this thread: I think for this
specific case I'd also prefer a separate new message, because that
makes it easier to filter that message out when received by PgBouncer.
But I'd still like to understand your viewpoint better on this,
because adding fields to existing message types is definitely one of
the types of changes that I personally think would be fine for some
protocol changes.
If this door is open then it has to very clear how multiple startup
parameters are handled at the protocol level, and that is a much bigger
fish because what happens if extensions add startup parameters as well.
Adding a new message could be the way forward, but that opens the door
for the wish-lists for v4.
Best regards,
Jesper
