On Fri, Jul 18, 2025 at 3:29 PM Daniel Gustafsson wrote:
> Ugh, In preparing for going on vacation this fell off the radar. I'll try to
> get to looking at it tomorrow during downtime unless beaten to it.
Your earlier mail made me worried I'd missed something, but is the
attached diff what Andre
> On 18 Jul 2025, at 19:26, Andres Freund wrote:
>> Hm, what problem did you encounter? I don't think there should be any
>> difficulty?
>
> Ping?
Ugh, In preparing for going on vacation this fell off the radar. I'll try to
get to looking at it tomorrow during downtime unless beaten to it.
--
Hi,
On 2025-06-30 19:42:51 -0400, Andres Freund wrote:
> On 2025-07-01 00:52:49 +0200, Daniel Gustafsson wrote:
> > > On 30 Jun 2025, at 20:33, Jacob Champion
> > > wrote:
> > >
> > > On Mon, Jun 30, 2025 at 10:02 AM Daniel Gustafsson
> > > wrote:
> > >>> On 30 Jun 2025, at 18:58, Andres Freu
On Thu, Jul 10, 2025 at 7:41 AM wrote:
> I agree with the patch. Works in my OSes
Thanks Ivan! Committed.
--Jacob
I agree with the patch. Works in my OSes
On 7/10/25 2:54 AM, Jacob Champion wrote:
On Wed, Jul 9, 2025 at 12:42 PM Tom Lane wrote:
> Nah, let's keep them. We do document for at least some libraries
> how to manually specify the include and link options without
> depending on pkg-config. If
On Wed, Jul 9, 2025 at 12:42 PM Tom Lane wrote:
> Nah, let's keep them. We do document for at least some libraries
> how to manually specify the include and link options without
> depending on pkg-config. If someone tries that with libcurl,
> it'd be good to have sanity checks on the results.
S
Jacob Champion writes:
> On Wed, Jul 9, 2025 at 12:07 PM Tom Lane wrote:
>> I'm confused about why this moves up the temporary changes of
>> CPPFLAGS and LDFLAGS, but not LIBS? Maybe that's actually correct,
>> but it looks strange (and perhaps deserves a comment about why).
> Does the attached
On Wed, Jul 9, 2025 at 12:07 PM Tom Lane wrote:
> Jacob Champion writes:
> > Here is a draft patch for Ivan's reported issue; I still need to put
> > it through its paces with some more unusual setups, but I want to get
> > cfbot on it.
>
> I'm confused about why this moves up the temporary chang
Jacob Champion writes:
> Here is a draft patch for Ivan's reported issue; I still need to put
> it through its paces with some more unusual setups, but I want to get
> cfbot on it.
I'm confused about why this moves up the temporary changes of
CPPFLAGS and LDFLAGS, but not LIBS? Maybe that's actu
On Wed, Jul 9, 2025 at 11:13 AM Tom Lane wrote:
> Jacob Champion writes:
> > I'll work up a patch to send through the CI. I can't currently test
> > RHEL8 easily -- Rocky 8 is incompatible with my Macbook? -- which I
> > will need to rectify eventually, but I can't this week.
>
> No need, I alrea
Jacob Champion writes:
> I'll work up a patch to send through the CI. I can't currently test
> RHEL8 easily -- Rocky 8 is incompatible with my Macbook? -- which I
> will need to rectify eventually, but I can't this week.
No need, I already tested locally. Will push shortly.
On Wed, Jul 9, 2025 at 10:36 AM Tom Lane wrote:
> Per "man dlopen", you have to link with libdl to use these functions
> on this platform. (Curiously, although RHEL9 still says that in the
> documentation, it doesn't seem to actually need -ldl.) I was able
> to resolve this by adding -ldl in lib
Hi,
On 2025-07-09 13:36:26 -0400, Tom Lane wrote:
> It doesn't look like the Meson support needs such explicit tracking of
> required libraries, but perhaps I'm missing something?
It should be fine, -ldl is added to "os_deps" if needed, and os_deps is used
for all code in pg.
Greetings,
Andres
Jacob Champion writes:
> On Wed, Jul 2, 2025 at 5:45 AM Ivan Kush wrote:
>> Why don't we set LIBS in the configure in "checking for curl_multi_init"
>> using LIBCURL_LIBS or LIBCURL_LDFLAGS?
>> [...]
>> Without these LIBCURL... variables we will check a system libcurl, not
>> our local.
> Ah, th
On Wed, Jul 2, 2025 at 5:45 AM Ivan Kush wrote:
>
> Thanks for the clarification! I thought linker flags should be installed
> globally for all compilation targets.
Not for libcurl, since the libpq-oauth module split.
> Another question:
>
> Why don't we set LIBS in the configure in "checking fo
Thanks for the clarification! I thought linker flags should be installed
globally for all compilation targets.
Another question:
Why don't we set LIBS in the configure in "checking for curl_multi_init"
using LIBCURL_LIBS or LIBCURL_LDFLAGS?
https://github.com/postgres/postgres/blob/master/co
Hi,
On 2025-07-01 00:52:49 +0200, Daniel Gustafsson wrote:
> > On 30 Jun 2025, at 20:33, Jacob Champion
> > wrote:
> >
> > On Mon, Jun 30, 2025 at 10:02 AM Daniel Gustafsson wrote:
> >>> On 30 Jun 2025, at 18:58, Andres Freund wrote:
> >>> Probably just needs to be added to the installed_targ
> On 30 Jun 2025, at 20:33, Jacob Champion
> wrote:
>
> On Mon, Jun 30, 2025 at 10:02 AM Daniel Gustafsson wrote:
>>> On 30 Jun 2025, at 18:58, Andres Freund wrote:
>>> Probably just needs to be added to the installed_targets list.
>>
>> Thanks for the report, I'll take a look today to get it
On Mon, Jun 30, 2025 at 10:02 AM Daniel Gustafsson wrote:
> > On 30 Jun 2025, at 18:58, Andres Freund wrote:
> > Probably just needs to be added to the installed_targets list.
>
> Thanks for the report, I'll take a look today to get it fixed.
Thanks both!
Looking at the installed_targets stuff,
> On 30 Jun 2025, at 18:58, Andres Freund wrote:
>
> Hi,
>
> On 2025-05-02 10:42:34 -0700, Jacob Champion wrote:
>> Great, thanks. I'll push it soon.
>
> I just noticed that I think the dependencies on the meson build aren't quite
> sufficient:
>
> andres@awork3:/srv/dev/build/postgres/m-dev-a
Hi,
On 2025-05-02 10:42:34 -0700, Jacob Champion wrote:
> Great, thanks. I'll push it soon.
I just noticed that I think the dependencies on the meson build aren't quite
sufficient:
andres@awork3:/srv/dev/build/postgres/m-dev-assert$ ninja install-quiet
[2205/2205 1 100%] Generating install-quiet
On Fri, Jun 20, 2025 at 3:08 AM Ivan Kush wrote:
>
> Hello!
>
> This patch fixes CPPFLAGS, LDFLAGS, LIBS when checking AsyncDNS libcurl
> support in configure
Hi Ivan, thanks for the report! Your patch puts new logic directly
after an AC_MSG_ERROR() call, so any effect has to come from the fact
t
Hello!
This patch fixes CPPFLAGS, LDFLAGS, LIBS when checking AsyncDNS libcurl
support in configure
Custom parameters and paths to libcurl were mistakenly excluded from
CPPFLAGS, LDFLAGS, and LIBS, although AsyncDNS check was OK.
For example, the command `pkg-config --libs libcurl` gives
`
On Thu, Mar 6, 2025 at 12:57 PM Jacob Champion
wrote:
> 3) There is a related performance bug on other platforms. If a Curl
> timeout happens partway through a request (so libcurl won't clear it),
> the timer-expired event will stay set and CPU will be burned to spin
> pointlessly on drive_request
On Sun, May 4, 2025 at 5:58 AM Wolfgang Walther wrote:
> The only inconsistency I was able to find is the autoconf-generated
> libpq.pc file, which has this:
>
>Requires.private: libssl, libcrypto libcurl
Oh, I see what I did. Will fix, thanks.
> I was only able to test the latter in an end-
Hi,
On Sat, 2025-05-03 at 16:54 +0200, Christoph Berg wrote:
> The package split between libpq5 and libpq-oauth in Debian has already
> been accepted into the experimental branch.
RPMs will ship postgresql18-libs and postgresql18-libs-oauth. The latter
depends on the former for sure.
Regards,
-
Jacob Champion:
libintl is already coming in via frontend_stlib_code, so that's fine.
So now I'm wondering if any other static clients of libpq-int.h (if
there are any) need the ssl dependency too, for correctness, or if
it's just me.
Looks like it's just me. And using partial_dependency for th
Re: Jacob Champion
> So, committed. Thanks everyone for all the excellent feedback!
The package split between libpq5 and libpq-oauth in Debian has already
been accepted into the experimental branch.
Thanks,
Christoph
Jacob Champion writes:
> On Fri, May 2, 2025 at 11:26 AM Tom Lane wrote:
>> Apropos of that: our fine manual claims that option is spelled
>> --auto_features, but that fails for me. Is that a typo in our
>> manual, or do some meson versions accept the underscore?
> --auto_features doesn't work
On Fri, May 2, 2025 at 11:56 AM Jacob Champion
wrote:
> -I/opt/homebrew/Cellar/openssl@3/3.5.0/include
Except it _is_ right there.
Oh, ha -- I'm not using Homebrew's Curl in this minimal build. Looks
like it's coming from the sysroot.
% ls -l
/Library/Developer/CommandLineTools/SDKs/MacOSX
On Fri, May 2, 2025 at 11:52 AM Tom Lane wrote:
> $ pkg-config --cflags libcurl
> -I/opt/local/include -I/opt/local/libexec/openssl3/include
> -I/opt/local/include
>
> I bet Homebrew's libcurl packaging doesn't do that.
Nope, Homebrew breaks them out into smaller pieces:
% PKG_CONFIG_PATH=/
Jacob Champion writes:
> Hm. If you clear out the build artifacts under
> src/interfaces/libpq-oauth, and then build with
> $ ninja -v src/interfaces/libpq-oauth/libpq-oauth.a
> does that help surface anything interesting?
$ rm -rf src/interfaces/libpq-oauth
$ ninja -v src/interfaces/libpq-oa
On Fri, May 2, 2025 at 11:26 AM Tom Lane wrote:
> Yeah, they are both under /opt/local/include in a MacPorts setup.
> But disabling NLS doesn't break it for me. I tried
>
> meson setup build --auto-features=disabled -Dlibcurl=enabled
>
> to make sure that /opt/local/include wasn't getting pulled
Jacob Champion writes:
> On Fri, May 2, 2025 at 10:35 AM Tom Lane wrote:
>> FWIW, on my Mac a meson build from HEAD goes through fine, with or
>> without this patch. I'm getting openssl and libcurl from MacPorts
>> not Homebrew, but I don't know why that would make any difference.
> Do your an
On Fri, May 02, 2025 at 10:42:25AM -0700, Jacob Champion wrote:
> On Fri, May 2, 2025 at 10:35 AM Tom Lane wrote:
>> FWIW, on my Mac a meson build from HEAD goes through fine, with or
>> without this patch. I'm getting openssl and libcurl from MacPorts
>> not Homebrew, but I don't know why that w
On Fri, May 2, 2025 at 10:31 AM Nathan Bossart wrote:
> Yup, thanks!
Great, thanks. I'll push it soon.
--Jacob
On Fri, May 2, 2025 at 10:35 AM Tom Lane wrote:
> FWIW, on my Mac a meson build from HEAD goes through fine, with or
> without this patch. I'm getting openssl and libcurl from MacPorts
> not Homebrew, but I don't know why that would make any difference.
Do your and live in the same place? Mine
Jacob Champion writes:
> Looks like it's just me. And using partial_dependency for the includes
> seems like overkill, so I've kept the full ssl dependency object, but
> moved it to the staticlib only, which is enough to solve the breakage
> on my machine.
> Nathan, if you get a chance, does the a
On Fri, May 02, 2025 at 10:05:26AM -0700, Jacob Champion wrote:
> Nathan, if you get a chance, does the attached patch work for you?
Yup, thanks!
--
nathan
On Fri, May 2, 2025 at 8:59 AM Jacob Champion
wrote:
> libintl is already coming in via frontend_stlib_code, so that's fine.
> So now I'm wondering if any other static clients of libpq-int.h (if
> there are any) need the ssl dependency too, for correctness, or if
> it's just me.
Looks like it's j
On Fri, May 2, 2025 at 8:46 AM Jacob Champion
wrote:
> Yeah, I wonder if libintl is being similarly "cheated" on the Meson side.
libintl is already coming in via frontend_stlib_code, so that's fine.
So now I'm wondering if any other static clients of libpq-int.h (if
there are any) need the ssl de
On Fri, May 2, 2025 at 8:11 AM Nathan Bossart wrote:
>
> After commit b0635bf, I'm seeing the following meson build failures on
> macOS:
Thanks for the report, and sorry for the breakage.
> In file included from
> ../postgresql/src/interfaces/libpq-oauth/oauth-curl.c:51:
> ../po
After commit b0635bf, I'm seeing the following meson build failures on
macOS:
In file included from
../postgresql/src/interfaces/libpq-oauth/oauth-curl.c:51:
../postgresql/src/interfaces/libpq/libpq-int.h:70:10: fatal error:
'openssl/ssl.h' file not found
70 | #include
On Mon, Apr 21, 2025 at 9:57 AM Jacob Champion
wrote:
> So to recap: I'm happy to add a Google compatibility mode, but I'd
> like to gather some evidence that their device flow can actually
> authorize tokens for third parties safely, before we commit to that.
> Thoughts?
Hi Ivan, I know the thre
On Thu, May 1, 2025 at 12:24 PM Jacob Champion
wrote:
> I'm running the attached fixup through CI now.
(Pushed, and indri is happy again.)
--Jacob
On Thu, May 1, 2025 at 10:38 AM Jacob Champion
wrote:
> I've thrown some more Autoconf testing at Rocky, Mac, and Ubuntu.
>
> So, committed.
I forgot --enable-nls in my Mac testing, so indri complains about my
omission of -lintl... I'd incorrectly thought it was no longer needed
after all the get
On Wed, Apr 30, 2025 at 11:09 AM Daniel Gustafsson wrote:
> I'll try to kick the tyres a bit more as well.
Thanks! Alpine seems to be happy with the dlopen() arrangement. And
I've thrown some more Autoconf testing at Rocky, Mac, and Ubuntu.
So, committed. Thanks everyone for all the excellent fe
> On 30 Apr 2025, at 19:59, Jacob Champion
> wrote:
> On Wed, Apr 30, 2025 at 5:55 AM Daniel Gustafsson wrote:
>> Nitpick, but it won't be .so everywhere. Would this be clearar if spelled
>> out
>> with something like "do not rely on libpq-int.h when building libpq-oauth as
>> dynamic shared
On Wed, Apr 30, 2025 at 5:55 AM Daniel Gustafsson wrote:
> > To keep things moving: I assume this is unacceptable. So v10 redirects
> > every access to a PGconn struct member through a shim, similarly to
> > how conn->errorMessage was translated in v9. This adds plenty of new
> > boilerplate, but
> On 29 Apr 2025, at 02:10, Jacob Champion
> wrote:
>
> On Wed, Apr 23, 2025 at 10:46 AM Jacob Champion
> wrote:
>> Are there any readers who feel like an internal ABI version for
>> `struct pg_conn`, bumped during breaking backports, would be
>> acceptable? (More definitively: are there any re
On Wed, Apr 23, 2025 at 10:46 AM Jacob Champion
wrote:
> Are there any readers who feel like an internal ABI version for
> `struct pg_conn`, bumped during breaking backports, would be
> acceptable? (More definitively: are there any readers who would veto
> that?)
To keep things moving: I assume t
On Fri, Apr 25, 2025 at 2:03 AM Christoph Berg wrote:
> My point is that we should be trying to change the ABI-as-coded-in-the-
> filename as rarely as possible.
I agree, but I'm also trying to say I can't unilaterally declare
pieces of our internal structs to be covered by an ABI guarantee.
Mayb
Re: Jacob Champion
> I think the system is overconstrained at that point. If you want to
> support clients that delay-load the ABI they're compiled against,
> _and_ have them continue to work seamlessly after the system has
> upgraded the ABI underneath them, without restarting the client... is
> t
On Wed, Apr 23, 2025 at 1:13 PM Christoph Berg wrote:
> Uhm, so far the plan was to have one "libpq-oauth" package, not several.
I think the system is overconstrained at that point. If you want to
support clients that delay-load the ABI they're compiled against,
_and_ have them continue to work s
Re: Jacob Champion
> Also: since the libpq-oauth-18 and libpq-oauth-19 packages can be
> installed side-by-side safely, isn't the upgrade hazard significantly
> diminished? (If a user uninstalls the previous libpq-oauth version
> while they're still running that version of libpq in memory, _and_
>
On Wed, Apr 23, 2025 at 9:38 AM Christoph Berg wrote:
> > We could all agree to bump the second number in the filename whenever
> > there's an internal ABI change. That works from a technical
> > perspective, but it's hard to test and enforce and... just not forget.
>
> It's hopefully not harder t
Re: Jacob Champion
> But the consequences are much worse for a silent ABI mismatch. Imagine
> if libpq-oauth examines the wrong pointer inside PGconn for a
> security-critical check.
True.
> > Alternatively, there could be a dedicated SONAME for the plugin that
> > only changes when necessary, bu
On Wed, Apr 23, 2025 at 8:39 AM Christoph Berg wrote:
> This will cause problems when programs are running while packages are
> updated on disk. That program then tries to dlopen 18-0.so when there
> is already 18-1.so installed. Relevant when the first oauth connection
> is made way after startup
Re: Jacob Champion
> - Per ABI comment upthread, we are back to major-minor versioning for
> the shared library (e.g. libpq-oauth-18-0.so). 0001 adds the macros
> and makefile variables to make this easy, and 0002 is the bulk of the
> change now.
This will cause problems when programs are running
On Tue, Apr 22, 2025 at 3:02 AM Daniel Gustafsson wrote:
> + if oauth_flow_supported
> +cdata.set('USE_LIBCURL', 1)
> + elif libcurlopt.enabled()
> +error('client OAuth is not supported on this platform')
> + endif
> We already know that libcurlopt.enabled() is true here so maybe just d
Hi Jacob, thank you for detailed explanation and links!
Am I right that classic OAuth flow "create user account based on a
token" is implemented using custom validators?
1) In pg_hba.conf set user to all and "delegate_ident_mapping=1"
"local all all oauth issuer=$issuer scope=$scope delegate
> On 22 Apr 2025, at 01:19, Jacob Champion
> wrote:
> v8 also makes the following changes:
Thanks for this version, a few small comments:
+ if oauth_flow_supported
+cdata.set('USE_LIBCURL', 1)
+ elif libcurlopt.enabled()
+error('client OAuth is not supported on this platform')
+ end
On Sat, Apr 19, 2025 at 5:04 AM Christoph Berg wrote:
> How about this:
>
> No libpq OAuth flows are available. (Try installing the libpq-oauth
> package.)
Tweaked for capitalization/punctuation rules, and removing the first
"libpq" mention (which I don't think helps a user of, say, psql):
Hi,
On Sat, 2025-04-19 at 14:03 +0200, Christoph Berg wrote:
> No libpq OAuth flows are available. (Try installing the libpq-oauth
> package.)
>
> People who have custom flows will likely know that they have to do
> anyway.
>
> Devrim: Does that match the package name you'd use?
On PGDG RPM w
On Sun, Apr 20, 2025 at 10:12 AM Ivan Kush wrote:
> I'm testing OAuth Device Flow implementation on Google. Met several
> problems.
Hi Ivan, thank you for testing and reporting! Unfortunately, yeah,
Google is a known problem [1]. They've taken several liberties with
the spec, as you point out.
W
Hello!
I'm testing OAuth Device Flow implementation on Google. Met several
problems.
Postgres from master branch, commit 764d501d24b
Google Device Flow API
https://developers.google.com/identity/protocols/oauth2/limited-input-device
1) In Device Authorization Request Google returns 428 code o
Re: Jacob Champion
> > libpq_append_conn_error(conn, "no custom OAuth flows are available,
> > and libpq-oauth could not be loaded library could not be loaded. Try
> > installing the libpq-oauth package from the same source that you
> > installed libpq from");
>
> Thanks! I think that's a little t
On Tue, Apr 15, 2025 at 2:38 PM Jelte Fennema-Nio wrote:
> libpq_append_conn_error(conn, "no custom OAuth flows are available,
> and libpq-oauth could not be loaded library could not be loaded. Try
> installing the libpq-oauth package from the same source that you
> installed libpq from");
Thanks
On Thu, Apr 17, 2025 at 5:47 PM Jacob Champion
wrote:
> With those, I have no more TODOs and I believe this is ready for a
> final review round.
Some ABI self-review. These references to conn->errorMessage also need
the indirection treatment, which I'm working on now:
> if (actx->errctx)
>
On Tue, 15 Apr 2025 at 19:53, Jacob Champion
wrote:
> But let me turn this around, because we currently have the opposite
> problem: if someone comes in and adds a completely new feature
> depending on libcurl, and you want OAuth but you do not want that new
> feature -- or vice-versa -- what do y
On Tue, Apr 15, 2025 at 12:21 PM Robert Haas wrote:
> I also don't mind being wrong, of course. But I think it's better to
> bet on making this like other things and then change strategy if that
> doesn't work out, rather than starting out by making this different
> from other things.
Works for m
On Tue, Apr 15, 2025 at 11:57 AM Christoph Berg wrote:
> What made me reconsider was Peter saying that what defines the blast
> radius of some feature is usually the extra dependency pulled in. If
> you don't like tracking OpenSSL problems, build without it. If you
> don't like libcurl, build with
On Tue, Apr 15, 2025 at 8:32 AM Peter Eisentraut wrote:
> On 10.04.25 01:08, Jacob Champion wrote:
> > Christoph noted that this was also confusing from the packaging side,
> > earlier, and Daniel proposed -Doauth-client/--with-oauth-client as the
> > feature switch name instead. Any objections? U
Re: Jacob Champion
> But there's no connection between "libcurl" and "OAuth Device
> Authorization flow" in anyone's mind except the people who have worked
> on that feature.
Fwiw that was exactly the reason I originally voiced the idea to
rename.
> But let me turn this around, because we current
On Tue, Apr 15, 2025 at 8:34 AM Christoph Berg wrote:
> I agree with this reasoning and retract my suggestion to rename the option.
(Thank you for chiming in; having the packager feedback has been
extremely helpful.)
While I have you, may I ask whether you're okay (from the packager
perspective)
On Tue, Apr 15, 2025 at 5:31 AM Peter Eisentraut wrote:
> On 10.04.25 01:08, Jacob Champion wrote:
> > Christoph noted that this was also confusing from the packaging side,
> > earlier,
Since Christoph has withdrawn the request, I will drop -0002.
However, I'll go ahead and put some of my opinio
Re: Peter Eisentraut
> But worse, what you are hiding is the information what dependencies
> you are pulling in, which is the actual reason for the options. (If there
> was no external dependency, there would be no option at all.)
>
> This seems unnecessarily complicated and inconsistent. Once y
On Mon, Apr 14, 2025 at 1:17 PM Jacob Champion
wrote:
> I believe so. I'm in the middle of the .pc stuff right now; v6 should
> have the fixes as long as I don't get stuck.
Done in v6-0001. I think this is now architecturally complete, so if
reviewers are happy I can work on docs and the commit m
Hi,
On 2025-04-11 18:21:14 +0200, Wolfgang Walther wrote:
> Jacob Champion:
> > On Wed, Apr 9, 2025 at 4:42 PM Jelte Fennema-Nio wrote:
> > > I think your suggestion of not using any .so files would best there (from
> > > w user perspective). I'd be quite surprised if a static build still
> > >
On 10.04.25 01:08, Jacob Champion wrote:
Christoph noted that this was also confusing from the packaging side,
earlier, and Daniel proposed -Doauth-client/--with-oauth-client as the
feature switch name instead. Any objections? Unfortunately it would
mean a buildfarm email is in order, so we shoul
On Mon, Apr 14, 2025 at 12:46 PM Wolfgang Walther
wrote:
> But that means we'd need a -lpq-oauth-18 or something like that in
> Libs.private in libpq.pc, right?
I believe so. I'm in the middle of the .pc stuff right now; v6 should
have the fixes as long as I don't get stuck.
Thanks,
--Jacob
Jacob Champion:
(The [2] link is missing, I think.)
Ah, sry. This is the link:
https://github.com/wolfgangwalther/nixpkgs/commits/postgresql-libpq-curl/
It's the last two commits on that branch.
I'm confused by this -- the build produces staticlibs alongside the
dynamically linked ones, so
Jacob Champion:
libpq.a
libpq-oauth-18.a
The libpq.a file has no references to dlopen, but plenty of references
to curl stuff.
Which references? libpq-oauth should be the only thing using Curl symbols:
$ nm src/interfaces/libpq/libpq.a | grep --count curl
0
$ nm src/interfaces/
On Mon, Apr 14, 2025 at 11:27 AM Wolfgang Walther
wrote:
>src/interfaces/libpq-oauth/meson.build:18:22: ERROR: File
> oauth-curl.c does not exist.
>
> This.. clears it up, because that file is indeed missing for me on disk.
Aha! Okay, glad I don't need to track that down.
> libpq.a
> libpq-o
Wolfgang Walther:
> So yes, not related to your patch. I do understand that PostgreSQL's
> autoconf build system is not designed for "static only", I am certainly
> not expecting you to fix that.
>
> I think meson will do better here, but I was not able to make that work,
> yet.
I did a basic meso
On Fri, Apr 11, 2025 at 9:21 AM Wolfgang Walther
wrote:
> I tried to apply this patch to nixpkgs' libpq build [1]. First, I pinned
> a recent commit from master (one where the v5 patch will apply cleanly
> later) and enabled --with-libcurl [2].
(The [2] link is missing, I think.)
> 2. The static
On 08.04.25 19:44, Jacob Champion wrote:
Would anybody following along be opposed to a situation where
- dynamiclib builds go through the dlopen() shim
- staticlib builds always rely on statically linked symbols
If this can be implemented in a straightforward way, that would be the
best way, I
Jacob Champion:
On Wed, Apr 9, 2025 at 4:42 PM Jelte Fennema-Nio wrote:
I think your suggestion of not using any .so files would best there (from w
user perspective). I'd be quite surprised if a static build still resulted in
me having to manage shared library files anyway.
Done this way in
On Wed, Apr 9, 2025 at 4:42 PM Jelte Fennema-Nio wrote:
> I think your suggestion of not using any .so files would best there (from w
> user perspective). I'd be quite surprised if a static build still resulted in
> me having to manage shared library files anyway.
Done this way in v5. I had pla
On Wed, Apr 9, 2025 at 1:14 AM Christoph Berg wrote:
> One design goal could be reproducible builds-alike, that is, have
> libpq configured with or without libcurl be completely identical, and
> the feature being present is simply the libpq-oauth.so file existing
> or not. That might make using pl
On Tue, Apr 8, 2025 at 9:02 AM Wolfgang Walther wrote:
> How does the proposal with a loadable module affect a static libpq.a?
The currently proposed patch would have you package and install a
separate .so module implementing OAuth, which the staticlib would load
once when needed. Similarly to ho
On Tue, Apr 8, 2025 at 2:32 PM Jacob Champion
wrote:
> I think the module should be using
> libpq's libpq_gettext(). (Which we could do, again through the magic
> of dependency injection.)
To illustrate what I mean, v3 introduces an initialization function
that names the three internal dependenci
On Mon, Apr 7, 2025 at 10:05 AM Andres Freund wrote:
> On 2025-04-07 09:41:25 -0700, Jacob Champion wrote:
> > Ah, you mean if the RPATH'd build doesn't have a flow, but the
> > globally installed one (with a different ABI) does? Yeah, that would
> > be a problem.
>
> That and more: Even if the RP
Re: Jacob Champion
> > Putting the minor version into the filename would make looking at
> > package diffs harder when upgrading. Do we really need this as opposed
> > to some hardcoded number like libpq.so.5.18 ?
> >
> > Perhaps reusing the number from libpq.so.5.18 also for this lib would
> > be
Hi all,
Thanks for all the feedback! I'll combine them all into one email:
On Mon, Apr 7, 2025 at 6:59 AM Peter Eisentraut wrote:
> Looks mostly ok. I need the following patch to get it to build on macOS:
> [...]
> (The second change is not strictly required, but it disables the use of
> -bundl
Hi,
On 2025-04-07 18:38:19 +0200, Peter Eisentraut wrote:
> On 07.04.25 16:43, Andres Freund wrote:
> > There recently was a breakage of building with PG on macos with meson, due
> > to
> > the meson folks implementing a feature request to move away from using
> > bundles, as
> > 1) bundles appar
> On 8 Apr 2025, at 17:04, Jacob Champion
> wrote:
>
> On Tue, Apr 8, 2025 at 7:32 AM Bruce Momjian wrote:
>> Uh, where are we on the inclusion of curl in our build? Maybe it was
>> explained but I have not seen it.
>
> The above is discussing a patch to split this into its own loadable
> mod
Jacob Champion:
It allows packagers to ship the OAuth library separately, so end users
that don't want the additional exposure don't have to install it at
all.
Ah, this came in after I sent my other mail, with this foot-note:
> Currently, the two build systems don't handle the "please build on
On Thu, Apr 10, 2025, 07:08 Jacob Champion
wrote:
> Christoph noted that this was also confusing from the packaging side,
> earlier, and Daniel proposed -Doauth-client/--with-oauth-client as the
> feature switch name instead.
>
+1
Next up: staticlibs.
>
I think your suggestion of not using any
On Wed, Apr 9, 2025 at 10:44 AM Christoph Berg wrote:
>
> Re: Jacob Champion
> > > How about ifdef-ing away the dlopen call if --with-libcurl is not
> > > specified.
> >
> > This sounds like a pretty decent, simple way to go. Christoph, does
> > that ring any alarm bells from your perspective?
>
1 - 100 of 374 matches
Mail list logo
