On Mon, Apr 7, 2025 at 9:41 AM Jacob Champion <jacob.champ...@enterprisedb.com> wrote: > > Not sure, the code looks correct at first glance. However, you could > > also just keep the libpq-oauth strings in the libpq catalog. There > > isn't really a need to make a separate one, since the versions you end > > up installing are locked to each other. So you could for example in > > libpq's nls.mk just add > > > > ../libpq-oauth/oauth-curl.c > > > > etc. to the files. > > Oh, that's an interesting idea. Thanks, I'll give it a try.
A consequence of this is that our copy of libpq_binddomain isn't using the same mutex as libpq's copy to protect the "libpq-18" message domain. We could discuss whether or not it matters, since we don't support Windows, but it doesn't feel architecturally sound to me. If we want to reuse the same domain, I think the module should be using libpq's libpq_gettext(). (Which we could do, again through the magic of dependency injection.) > > Maybe it would also make sense to make libpq-oauth a subdirectory of the > > libpq directory instead of a peer. > > Works for me. It does not, however, work for our $(recurse) setup in the makefiles -- a shared library depending on a parent directory's shared library leads to infinite recursion, with the current tools -- so I'll keep it at the current directory level for now. Thanks, --Jacob
