Re: libpq: Bump protocol version to version 3.2 at least until the first/second beta

On Wed Jan 14, 2026 at 9:23 PM CET, Jacob Champion wrote:
> Partial review follows, in a v4 squash! set, as requested on the Discord :)

All changes in those 3 additional patches look totally reasonable to me.

> = Additional Thoughts =
>
> I want to more clearly decouple ourselves from TLS's GREASE in the
> documentation and comments. We aren't "Generating Random Extensions"
> (we _could_, but that takes a lot more thought), nor are we telling
> OpenSSL to enable GREASE for our TLS connections. It's fine if we want
> to gesture in that direction as broader context, but I don't want to
> cause user confusion. I'll work on some proposed changes for that.

Yeah, I didnt't realize that since TLS GREASE it became a broader term.
Definitely seems reasonable to reference the generic grease RFC instead
(which you have shared in the other protocol thread I think). So yeah
feel free to change the docs/comments to your heart's content.

> I'd like reserve a (protected?) wiki page, or something of the sort,
> that we can point people to directly if they hit any grease failures.
> "Server screwed up" is probably not enough context for a typical user
> to know what to do next.

Seems sensible to have a place to explain something to authors. Why not
put it directly in the protocol docs though? (I'd be fine with a wiki
too, but a docs page is protected by definition)

> I will also work on splitting 0002 into revertable and not-revertable
> halves. The grease constant probably needs to remain documented and
> reserved even if it doesn't do anything for 19.0.
>
> Finally: is there any appetite for retaining the ability to grease
> connections as production functionality, e.g. via
> `max_protocol_version=grease`? Personally I think it'd be nice, but
> it's not a trivial amount of extra work. We'd have to handle the case
> where a future server responds with a legitimate minor version that's
> newer than what our version of libpq supports. And I think we'd want a
> production-grade version of this to add some randomization tricks, to
> discourage people from keying on grease constants.

Both the patch split and max_protocol_version=grease sound reasonable to
me. I'd definitely like to keep all the grease code present on the main
branch, so we can keep using grease by default there.

I think max_protocol_version=grease makes a lot of sense. Because we
really want to make it as easy as possible for people to try out their
implementation of the negotation (see this for example[1])

If we do that then the patch split would be fairly minimal I expect.
i.e. it should only change the libpq default value, and the accompanying
test that tests the default value.

[1]: https://github.com/pgdogdev/pgdog/issues/578#issuecomment-3437244304