For the first commits I only have a few more questions/comments about
the error messages, otherwise looks good.
> > + libpq_append_conn_error(conn, "failed to lock mutex (%d)", lockerr);
> > + return 0;
> > + }
> > Shouldn't this path return -1,
>
> We could. I chose zero to try to retain the PG18 behavior, but I could
> expand this error message and set request->error instead. If that'd be
> less confusing to you as a reader, it's probably worth the change.
If this returns 0, we print out
failed to lock mutex
no OAuth flows are available (try installing the libpq-oauth package)
Which isn't ideal, as the library is there, so installing the package
wouldn't help.
+ if ((start_flow = dlsym(state->flow_module, "pg_start_oauthbearer")) == NULL)
And this path has the same issue, the library is there, so suggesting
to install libpq-oauth isn't helpful.
The more detailed message is only printed out with unsafe debugging,
without that it just returns 0.
+ appendPQExpBuffer(&conn->errorMessage,
+ "use_builtin_flow: failed to lock mutex (%d)\n",
+ lockerr);
This is after an assert, so maybe it is okay as is, but this bypasses
gettext. (or shouldn't it use "internal error:" similarly to the other
untranslated error message? and another 2 internal errors are
translated)
> (try installing the libpq-oauth package)
This isn't changed in these patches, but Is it okay to assume a
package name here? This is not a package that universally exists
everywhere, we can't even be sure that pg was installed with a package
manager. On RHEL it is called postgresql18-libs-oauth, on suse it's
part of the main libpq package. In both cases if for some internal
error it can't find/load the library, we suggest installing a package
that doesn't exist on that system.
