On Thu, Apr 3, 2025 at 12:50 PM Daniel Gustafsson <daniel@yesql.se> wrote:
> Thanks, both LGTM so pushed.
Thank you!
On Tue, Apr 1, 2025 at 3:40 PM Jacob Champion
<jacob.champion@enterprisedb.com> wrote:
> Maybe a better idea would be to ship an SONAME of
> `libpq-oauth.so.0.<major>`, without any symlinks, so that there's
> never any ambiguity about which module belongs with which libpq.
While I was looking into this I found that Debian's going to use the
existence of an SONAME to check other things, which I assume will make
Christoph's life harder. I have switched over to
'libpq-oauth-<major>.so', without any SONAME or symlinks.
v2 simplifies quite a few things and breaks out the new duplicated
code into its own file. I pared down the exports from libpq, by having
it push the pg_g_threadlock pointer directly into the module when
needed. I think a future improvement would be to combine the dlopen
with the libcurl initialization, so that everything is done exactly
once and the module doesn't need to know about threadlocks at all.
i18n is still not working correctly on my machine. I've gotten `make
init-po` to put the files into the right places now, but if I fake a
.po file and install the generated .mo, the translations still don't
seem to be found at runtime. Is anyone able to take a quick look to
see if I'm missing something obvious?
I still need to disable the module entirely on Windows (and other
platforms without support), and potentially rename the --with-libcurl
option.
Thanks,
--Jacob
