On Wed, 17 Jan 2024 at 14:39, Robert Haas <robertmh...@gmail.com> wrote: > I think it's hard to say for sure what API is going to work well here, > because we just don't have much experience with this.
Agreed, but I strongly believe PQunsupportedProtocolExtensions() is useful regardless of the API choice. > I also think that the reason why > the API you're proposing here looks good in this case is because libpq > itself doesn't really need to do anything differently for these > parameters. It doesn't actually really change anything about the > protocol; it only nails down the server behavior in a way that can't > be changed. Another current request is to have a way to have certain > data types always be sent in binary format, specified by OID. Do we > want that to be written as PQsetParameter("always_binary_format", > "123,456,789,101112") or do we want it to maybe look more like > PQalwaysBinaryFormat(int count, Oid *stuff)? Or, another example, say > we want to set client_to_server_compression_method=lz4. I think from libpq's perspective there are two categories of protocol extension parameters: 1. parameters that change behaviour in a way that does not matter to libpq 2. parameters that change in such a way that libpq needs to change its behaviour too (by parsing or sending messages differently than it normally would). _pq_.protocol_roles, _pq_.report_parameters, and (afaict) even _pq_.always_binary_format would fall into category 1. But _pq_.client_to_server_compression_method would fall into category 2, because libpq should start to compress the messages that it is sending. I think if you look at it like that, then using PQsetParameter for parameters in category 1 makes sense. And indeed you'd likely want a dedicated API for each parameter in category 2, and probably have PQsetParameter error for these parameters. In any case it seems like something that can be decided on a case by case basis. However, to make this future proof, I think it might be best if PQsetParameter would error for protocol extension parameters that it does not know about. > Also, I never intended for _pq_ to become a user-visible namespace > that people would have to care about I agree that forcing Postgres users to learn about this prefix is probably unwanted. But requiring client authors to learn about the prefix seems acceptable to me.