On Fri, 16 Aug 2024 at 00:39, Jacob Champion <jacob.champ...@enterprisedb.com> wrote: > > On Thu, Aug 15, 2024 at 3:04 PM Heikki Linnakangas <hlinn...@iki.fi> wrote: > > Perhaps we should even change it to return > > 300000 for protocol version 3.0, and just leave a note in the docs like > > "in older versions of libpq, this returned 3 for protocol version 3.0". > > I think that would absolutely break current code. It's not uncommon > (IME) for hand-built clients wrapping libpq to make sure they're not > talking v2 before turning on some feature, and they're allowed to do > that with a PQprotocolVersion() == 3 check. A GitHub code search > brings up examples.
Can you give a link for that code search and/or an example where someone used it like that in a real setting? The only example I could find where someone used it at all was psycopg having a unittest for their python wrapper around this API, and they indeed used == 3. > As for 30001: I don't see the value in modifying an exported API in > this way. Especially since we can add a new entry point that will be > guaranteed not to break anyone, as Robert suggested. I think it's a > POLA violation at minimum; my understanding was that up until this > point, the value was incremented during major (incompatible) version > bumps. And I think other users will have had the same understanding. The advantage is not introducing yet another API when we already have one with a great name that no-one is currently using. The current API is in practice just a very convoluted way of writing 3. Also doing an == 3 check is obviously problematic, if people use this function they should be using > 3 to be compatible with future versions. So if we ever introduce protocol version 4, then these (afaict theoretical) users would break anyway.
