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?
>
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?
Ok for me. The opposite that I said in the other mail was just a
suggestio
On Wed, Apr 9, 2025, 10:58 Jacob Champion
wrote:
> Is it acceptable/desirable for a build, which has not been configured
> --with-libcurl, to still pick up a compatible OAuth implementation
> installed by the distro? If so, we can go with a "bare" dlopen(). If
> that's not okay, I think we will p
Re: Jacob Champion
> Is it acceptable/desirable for a build, which has not been configured
> --with-libcurl, to still pick up a compatible OAuth implementation
> installed by the distro? If so, we can go with a "bare" dlopen(). If
> that's not okay, I think we will probably need to use pkglibdir or
Hi,
On 2025-04-07 09:41:25 -0700, Jacob Champion wrote:
> On Mon, Apr 7, 2025 at 7:21 AM Andres Freund wrote:
> > On 2025-04-04 17:27:46 -0700, Jacob Champion wrote:
> > I think otherwise
> > we run into the danger of the wrong library version being loaded in some
> > cases. Imagine a program bei
> On 8 Apr 2025, at 04:10, Jacob Champion
> wrote:
>
> On Mon, Apr 7, 2025 at 3:26 PM Jacob Champion
> wrote:
>> Sounds good. Any opinions from the gallery on what a "libpq plugin
>> subdirectory" in pkglibdir should be called? ("client", "modules",
>> "plugins"...?)
>
> Hm, one immediate cons
On Mon, Apr 7, 2025 at 2:58 PM Christoph Berg wrote:
> Why is this module worse? (I guess the answer is internal data
> structures... but does it have to be worse?)
It doesn't have to be, in general, and the coupling surface is small
enough (libpq_append_conn_error) that we have a relatively easy
On Tue, Apr 8, 2025 at 09:17:03AM -0700, Jacob Champion wrote:
> On Tue, Apr 8, 2025 at 9:14 AM Bruce Momjian wrote:
> > How does this patch help us avoid having to handle curl CVEs and its
> > curl's additional dependencies? As I understand the patch, it makes
> > libpq _not_ have additional de
On Tue, Apr 8, 2025 at 06:57:18PM +0200, Wolfgang Walther wrote:
> Jacob Champion:
> > On Tue, Apr 8, 2025 at 9:32 AM Wolfgang Walther
> > wrote:
> > > And that should also not be a problem for distributions - they could
> > > offer a libpq and a libpq_oauth package, where only one of them can
On Mon, Apr 7, 2025 at 9:41 AM Jacob Champion
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 lo
Jacob Champion:
On Tue, Apr 8, 2025 at 9:32 AM Wolfgang Walther wrote:
And that should also not be a problem for distributions - they could offer a
libpq and a libpq_oauth package, where only one of them can be installed at the
same time, I guess? *
My outsider understanding is that maintain
On Tue, Apr 8, 2025 at 06:42:19PM +0200, Daniel Gustafsson wrote:
> > On 8 Apr 2025, at 18:33, Bruce Momjian wrote:
>
> > Would we have to put out minor releases for curl CVEs? I don't think we
> > have to for OpenSSL so would curl be the same?
>
> Why do you envision this being different from
On Tue, Apr 8, 2025 at 3:34 AM Daniel Gustafsson wrote:
> > On 8 Apr 2025, at 04:10, Jacob Champion
> > wrote:
> > Hm, one immediate consequence of hardcoding pkglibdir is that we can
> > no longer rely on LD_LIBRARY_PATH for pre-installation testing.
> > (Contrast with the server, which is able
On Tue, Apr 8, 2025 at 11:25 AM Bruce Momjian wrote:
> However, is this
> true for libpq libraries or database server libraries. Does it matter?
The dependency on Curl is through libpq. We have some server-side
features that pull in libpq and would transitively depend on Curl. But
for Curl to be
On Tue, Apr 8, 2025 at 10:36 AM Jacob Champion
wrote:
> Yeah, but it's one of those things that feels like it must have been
> solved by the others in the space. Once it's installed, the concern
> goes away (unless you demand absolute relocatability without
> recompilation). I'll take a look at ho
On Tue, Apr 8, 2025 at 02:11:19PM -0400, Andres Freund wrote:
> Hi,
>
> On 2025-04-08 13:02:11 -0400, Bruce Momjian wrote:
> > On Tue, Apr 8, 2025 at 06:57:18PM +0200, Wolfgang Walther wrote:
> > > Jacob Champion:
> > > > On Tue, Apr 8, 2025 at 9:32 AM Wolfgang Walther
> > > > wrote:
> > > > >
Hi,
On 2025-04-08 13:02:11 -0400, Bruce Momjian wrote:
> On Tue, Apr 8, 2025 at 06:57:18PM +0200, Wolfgang Walther wrote:
> > Jacob Champion:
> > > On Tue, Apr 8, 2025 at 9:32 AM Wolfgang Walther
> > > wrote:
> > > > And that should also not be a problem for distributions - they could
> > > >
On Tue, Apr 8, 2025 at 10:10 AM Wolfgang Walther
wrote:
> And if that means making libpq modular at run-time, then this should be
> planned and built with all deps, and other use-cases (like static linking) in
> mind - and not like it is right now.
I think that'd be neat in concept, but specifi
On Tue, Apr 8, 2025 at 9:32 AM Wolfgang Walther wrote:
> This means that shipping another .so file will not happen with this approach.
> Assuming OAuth will be picked up by some of the bigger providers, that
> would... make me feel quite bad about it, actually.
It occurs to me that I didn't res
On Tue, Apr 8, 2025 at 10:15 AM Bruce Momjian wrote:
> Well, if we think we are going to do that, it seems we would need a
> different architecture than the one being proposed for PG 18, which
> could lead to a lot of user/developer API churn.
A major goal of the current patch proposal is to expl
On Tue, Apr 8, 2025 at 10:13:46AM -0700, Jacob Champion wrote:
> On Tue, Apr 8, 2025 at 10:10 AM Wolfgang Walther
> wrote:
> > And if that means making libpq modular at run-time, then this should be
> > planned and built with all deps, and other use-cases (like static linking)
> > in mind - and
On Tue, Apr 8, 2025 at 9:57 AM Wolfgang Walther wrote:
> if it's really the case that cURL is that much worse
(it is not, but I am sympathetic to the argument that if you don't use
it, you don't need it in the process space)
> However, if the other deps are considered problematic as well, then t
Jacob Champion:
However, if the other deps are considered problematic as well, then the
ship has already sailed, and there is not point for a special case here
anymore.
I think this line of argument is unlikely to find traction. Upthread
there were people asking if we could maybe split out other
On Tue, Apr 8, 2025 at 10:00:56AM -0700, Jacob Champion wrote:
> On Tue, Apr 8, 2025 at 9:49 AM Bruce Momjian wrote:
> > On Tue, Apr 8, 2025 at 09:43:01AM -0700, Jacob Champion wrote:
> > > By adding the new .so to a different package. For example, RPM specs
> > > would just let you say "hey, th
On Tue, Apr 8, 2025 at 9:49 AM Bruce Momjian wrote:
> On Tue, Apr 8, 2025 at 09:43:01AM -0700, Jacob Champion wrote:
> > By adding the new .so to a different package. For example, RPM specs
> > would just let you say "hey, this .so I just built doesn't go into the
> > main client package, it goes
1 - 100 of 350 matches
Mail list logo
