On Mon, Apr 7, 2025 at 9:41 AM Jacob Champion
<jacob.champion@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
