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
&g
On Fri, Jun 6, 2025 at 1:18 PM Nico Williams wrote:
> However no one will be using a discrete or firmware TPM for TLS server
> certificate private key usage: discrete TPMs are way way too slow for
> that, and firmware TPMs are... also way too slow. You wouldn't bother
> with a software TPM for th
On Fri, Jun 6, 2025 at 9:37 AM Andres Freund wrote:
> It's not just crashes, e.g. the startup packet timeout is also handled by
> _exit() - and it can be triggered remotely.
Fair point...
> ISTM that if crypto providers
> can't handle _exit(), we have a bigger problem.
...so I guess I need to f
On Fri, Jun 6, 2025 at 9:25 AM Nico Williams wrote:
> I'd expect all subsystems to recover cleanly from unclean shutdowns. I
> know, that's a lot to expect, but nowadays pretty much all filesystems
> used in production do, for example.
I guess, but if we stop cleaning up entirely, we will sudden
On Fri, Jun 6, 2025 at 7:17 AM Tom Lane wrote:
> Peter Eisentraut writes:
> > Since we now require Python 3.6, we can also remove PL/Python test
> > alternative expected files for earlier Python versions. See attached patch.
>
> +1. So nice to get rid of src/pl/plpython/expected/README.
Awesom
On Fri, Jun 6, 2025 at 4:56 AM Peter Eisentraut wrote:
> It seems weird to me that openssl spends so much effort tidying up its
> memory allocations just before exiting. We could just skip that.
> Looking through the code of OPENSSL_cleanup(), there might be one or two
> cases of log or trace fil
On Tue, Jun 3, 2025 at 12:48 AM Peter Eisentraut wrote:
>
> On macOS, when building with the make system, the exported symbols list
> (SHLIB_EXPORTS) is ignored. I don't think that is intentional. It was
> probably just forgotten, since that combination has never actually been
> used until now (
On Wed, May 28, 2025 at 2:59 PM Tom Lane wrote:
> (That should make the above-depicted elog unreachable, but
> belt and suspenders too isn't a bad plan.)
I like that approach, if delegation on Mac ends up being too much of a pain.
--Jacob
On Wed, May 28, 2025 at 9:25 AM Jacob Champion
wrote:
> Personally, I'd be more happy to "maintain GSS on Mac using
> non-deprecated interfaces" than "maintain GSS via Heimdal,
> best-effort, some of the time". I think the former puts less of a
> burden
On Wed, May 28, 2025 at 8:53 AM Tom Lane wrote:
> Even granting that we're okay with letting people build against
> Heimdal, I'm not clear on the path forward. Your patch proposes
> to effectively disable gss_accept_delegation, which isn't real
> palatable (and would require docs and test fixes t
On Thu, May 8, 2025 at 11:38 PM Heikki Linnakangas wrote:
> It didn't occur to me that you could write it simply as 'msgLength - 4'.
> That depends on knowing that the preceding fields are exactly 4 bytes
> long, but that's clear enough if we just add a comment on that, see
> attached.
Sorry for
On Wed, May 21, 2025 at 12:54 PM Melanie Plageman
wrote:
> Attached is a patch that updates these as well as changes all usages
> of log_connections in the tests. I made some judgment calls about
> where we might want expanded or reduced log_connections aspects. As
> such, the patch could use a on
On Mon, May 19, 2025 at 6:23 AM Aleksander Alekseev
wrote:
> In my experience people who have been contributing for some time use
> format-patch and provide at least a draft of the commit message,
> because they know it's more convenient both for the reviewers (the
> patch has better chances to be
On Fri, May 16, 2025 at 12:12 PM Tom Lane wrote:
> That outcome seems entirely horrible to me. If you want to flag the lack
> of a commit message somehow, fine, but don't prevent CI from running.
Personally I also prefer nudges to gates. Just like people already
deprioritize "Waiting on Author"
On Mon, May 12, 2025 at 8:49 AM Jacob Champion
wrote:
>
> On Mon, May 12, 2025 at 3:50 AM Christoph Berg wrote:
> > Since nothing in libpq should need curl for compiling, should we drop
> > it there instead?
>
> The static build (libpq.a) still needs libcurl. The modul
On Mon, May 12, 2025 at 3:50 AM Christoph Berg wrote:
> Since nothing in libpq should need curl for compiling, should we drop
> it there instead?
The static build (libpq.a) still needs libcurl. The module is only
compiled for use by the shared library.
--Jacob
On Thu, May 8, 2025 at 12:11 PM Heikki Linnakangas wrote:
> Polished this up a tiny bit, and committed.
Thanks! I think the uint8->int change for cancel_key_len is more than
just cosmetic; it most likely fixes a bug where a key size of 256
wrapped around to 0. I'll double-check that this fixes th
On Thu, May 8, 2025 at 1:07 PM Tom Lane wrote:
> I'm not aware of one, but it seems like a reasonable idea ...
I've created a skeleton at
https://wiki.postgresql.org/wiki/Minimum_Dependency_Versions, based on
our dev documentation and some recent threads. Still plenty to fill
in, if anyone knows
On Thu, May 8, 2025 at 5:22 AM Aleksander Alekseev
wrote:
> Thanks for the patch. It looks good to me. It's well documented and
> covered with tests. I can confirm that the tests pass. Also they fail
> if I decrease the $nesting_limit value to 15.
Thanks for the review!
--Jacob
On Wed, May 7, 2025 at 3:39 PM Álvaro Herrera wrote:
> Well, Jacob did say that he tested it with 3.81, so this patch should be
> okay. Upping the minimum version can be discussed elsewhere ... or
> maybe never, if we end up replacing it wholesale with Meson/ninja.
To be fair, I did invite debat
On Wed, May 7, 2025 at 2:45 PM Jonathan S. Katz wrote:
> I did a double take on the current sentence, and revised it to:
>
> ==
> PostgreSQL 18 introduces `oauth` authentication, which lets users
> authenticate using OAuth 2.0 mechanisms supported through PostgreSQL
> extensions.
> ==
>
> I don't
On Tue, May 6, 2025 at 8:46 PM Jonathan S. Katz wrote:
> Here's the next update
Thanks!
> PostgreSQL 18 introduces `oauth` authentication, which people can create
> extensions that support OAuth 2.0 based authentication mechanisms that
> PostgreSQL can authenticate with.
Suggested alternative
On Wed, May 7, 2025 at 11:55 AM Fabrízio de Royes Mello
wrote:
> LGTM
Thanks for the review!
>> Tested with GNU Make 3.81 (the compilation of which was slightly
>> painful; does anyone want to debate pulling that minimum version up
>> sometime soon?) and 4.3.
>
> Not sure if all animals have a m
Hi all,
I forgot to put a recursion limit in the new OAuth parsers; the
server-side depth checks don't apply to the client, and it's not using
the incremental parser to move the burden from the stack to the heap.
Luckily, we track the nesting level already, so a fix (attached) can
be pretty small.
Hello!
Wolfgang reported over in [1] that I've missed a comma when appending
to the PKG_CONFIG_REQUIRES_PRIVATE list, making libpq.pc look ugly:
Requires.private: libssl, libcrypto libcurl
pkg-config itself appears to be papering over my mistake (a quick code
inspection suggests it treats co
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 all,
A connection with only a hostaddr (no host) can't be cancelled via
PQcreateCancel(), because we'll crash in emitHostIdentityInfo(). The
problem is that the synthetic connhost entry we've created for
cancellation has an incorrect type field, which causes the following
code to make bad decis
On Thu, May 1, 2025 at 7:44 PM Bruce Momjian wrote:
> https://momjian.us/pgsql_docs/release-18.html
> +Add support for the "oauth" authentication (Jacob Champion, Daniel
> Gustafsson, Thomas Munro)
Should be either 'support for "oauth" authenti
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/Com
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=/
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
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
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'
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
ther
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
On Thu, May 1, 2025 at 7:44 PM Bruce Momjian wrote:
> I will probably add markup in 1-3 weeks. Let the feedback begin. ;-)
Thanks!
>
> Version 18 contains a number of changes that may affect compatibility
> with previous releases. Observe the following incompatibilities:
>
>
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
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 n
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 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 Tue, Apr 29, 2025 at 8:57 AM Jacob Champion
wrote:
> Cool, I will plan to push this Sometime Soon, then.
This is now committed. Thanks everybody!
--Jacob
On Mon, Apr 28, 2025 at 6:49 PM Noah Misch wrote:
> > Subject: [PATCH 1/2] oauth: Disallow OAuth connections via
> > postgres_fdw/dblink
> > Subject: [PATCH 2/2] oauth: Classify oauth_client_secret as a password
>
> Both look good.
Committed. Thanks for the review!
--Jacob
On Tue, Apr 29, 2025 at 8:46 AM Peter Eisentraut wrote:
> > On the reading that "supported" means "we'll try to fix a problem
> > rather than telling you to use a newer Python", I suspect that the
> > correct thing to say is 3.6.8 not 3.6. There may be no difference
> > in practice; but if push c
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 movi
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
On Thu, Apr 24, 2025 at 3:16 PM Jelte Fennema-Nio wrote:
> Why is this dangerous? As long as we'd validate that the provided cert
> by the server is for example.com
I can't help but read this as "as long as everyone mitigates the
danger, what's the danger?" We won't be the only implementers of an
On Thu, Apr 24, 2025 at 5:00 AM Peter Eisentraut wrote:
> Another detail to think about is how this affects psql -h localhost. In
> principle, this should require full SSL, but you're probably not going
> to have certificates that allow "localhost". And connections to
> localhost are the default
On Wed, Apr 23, 2025 at 8:47 AM George MacKerron wrote:
> I’d suggest two new special sslrootcert values:
>
> (1) sslrootcert=openssl
>
> This does exactly what sslrootcert=system does now, but is less confusingly
> named for Windows users. sslrootcert=system becomes a deprecated synonym for
> 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
On Thu, Apr 24, 2025 at 5:00 AM Peter Eisentraut wrote:
> I'm generally in favor of making sslmode=verify-full the effective
> default somehow.
+many
On Thu, Apr 24, 2025 at 3:53 AM Christoph Berg wrote:
> For
> postgresql://-style strings, we would ideally have something like http://
> vs http
On Thu, Apr 24, 2025 at 7:59 AM Tom Lane wrote:
> I'm still content with the idea of deciding that 3.6 is now our
> cutoff.
Seems like no one is pushing hard for an earlier version, yet, so
here's a patch with your suggested wording from upthread. I'm not sure
if this meets Peter's request for pr
On Wed, Apr 23, 2025 at 2:11 AM Jelte Fennema-Nio wrote:
> I'm confused. Are you intending to backport new test infra to PG18?
Not particularly (though, if the barriers were low enough, wouldn't
that be nice?). I'm talking about hazards in oauth_server.py here.
> Given the purpose and pretty sma
On Wed, Apr 23, 2025 at 4:24 AM Devrim Gündüz wrote:
> psycopg is included in RHEL 8, but PGDG packages are up2date (2.7.5 vs
> 2.9.5) so they override OS packages. That is why things will break.
Thanks, this is super helpful!
--Jacob
On Tue, Apr 22, 2025 at 12:45 PM Jacob Champion
wrote:
> Great, thanks for the quick review!
And pushed. Thanks everyone!
--Jacob
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
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
On Tue, Apr 22, 2025 at 3:10 AM Daniel Gustafsson wrote:
> My preference is that no operation can silently work on a failed object, but
> it's not a hill (even more so given where we are in the cycle).
Hm, okay. Something to talk about with Andrew and Peter, maybe.
> The attached
> v3 allocates
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
On Tue, Apr 22, 2025 at 3:17 PM Jelte Fennema-Nio wrote:
> The way you replaced this does not have the same behaviour in the case
> where the prefix/suffix is not part of the string. removeprefix/suffix
> will not remove any characters in that case, but your code will always
> remove the number of
On Tue, Apr 22, 2025 at 3:04 PM Tom Lane wrote:
> The fact that Jacob was able to fix
> oauth_server.py without (it seemed like) very much work seems to
> bear out that opinion.
I think my ability to do it should not be used as evidence of "ease".
I knew where to download 3.6, that I should buil
On Tue, Apr 22, 2025 at 2:43 PM Renan Alves Fonseca
wrote:
> I did a quick test on 3.5.
Thanks!
> It seems to work after removing
> f-strings... At this point, I would be really happy with 3.6.
Ah, makes sense. Well, I'm starting with the 3.6 fix regardless, since
it's preventing RHEL8 testing.
On Tue, Apr 22, 2025 at 2:28 PM Jelte Fennema-Nio wrote:
> I'm pretty sure most users of RHEL expect most modern software not to
> compile/work completely effortlessly on their distros without some
> effort on their part or on the part of RHEL packagers. That's kinda
> what you're signing up for i
On Tue, Apr 22, 2025 at 12:36 PM Tom Lane wrote:
> Thanks! I confirm this works for me on RHEL8 with 3.6.8.
Great, thanks for the quick review!
I'm considering committing this myself. Do you mind if it takes a day
or so to get this in, while I quadruple-check everything, or are you
blocked on t
On Tue, Apr 22, 2025 at 12:09 PM Renan Alves Fonseca
wrote:
> The oldest non EOL version is 3.9 right now. My suggestion is to follow
> the official supported releases.
I think this policy is too aggressive. Many operating systems we
support are going to ship Python versions past their EOL date (
On Tue, Apr 22, 2025 at 8:29 AM Jacob Champion
wrote:
> On Tue, Apr 22, 2025 at 8:05 AM Tom Lane wrote:
> > The first problem is that this Python version seems not to
> > like assignments embedded in if statements: [...]
> >
> > I was able to work around that w
On Tue, Apr 22, 2025 at 9:04 AM Tom Lane wrote:
> I'm also not excited by the idea that an incidental
> test script gets to dictate what the cutoff is.
I agree, and I don't intend for the script to dictate that.
> Maybe it's sufficient to make a documentation change here, and
> say we support Py
On Tue, Apr 22, 2025 at 8:05 AM Tom Lane wrote:
> The first problem is that this Python version seems not to
> like assignments embedded in if statements: [...]
>
> I was able to work around that with the attached quick hack.
> But then I get [...]
Thanks, I'll put a patch together. Sorry -- IIRC
: libpq = declare_dependency(
+ # libpq-oauth needs libcurl. Put both into *.private.
+ private_deps += [
+libpq_oauth_deps,
-+'-lpq-oauth-@0@'.format(pg_version_major),
++'-lpq-oauth',
+ ]
+endif
+
@@ src/test/modules/oauth_val
On Mon, Apr 21, 2025 at 11:46 AM Daniel Gustafsson wrote:
> We do, but with the current coding we call setJsonLexContextOwnsTokens
> immediately after creation which derefences the pointer without checkinf for
> allocation failure.
Right. (The flag does nothing on the OOM sentinel.)
> This means
On Mon, Apr 21, 2025 at 11:20 AM Daniel Gustafsson wrote:
> Sure, but I fear we'll get an endless stream of static analysis reports for
> the
> allocation leaking if we don't free it.
But we do free it, in freeJsonLexContext(). That usage of the API goes
back to 2023, with 1c99cde2f344. Or am I
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
On Sat, Apr 19, 2025 at 2:15 PM Daniel Gustafsson wrote:
> Since there is no way to determine if the allocation succeeded from outside of
> the JSON api it might be better to keep the calloc and explicitly free it?
I don't think so; pg_parse_json() will error out quickly, so I don't
see much adva
On Tue, Apr 15, 2025 at 11:11 PM Jelte Fennema-Nio wrote:
> On Wed, 16 Apr 2025 at 02:03, Jacob Champion
> wrote:
> > Thank you for saying something; I'd hallucinated that srvoptions was
> > limited to the server owner, and that's not true. It's pg_user_ma
On Fri, Apr 18, 2025 at 12:46 PM Tom Lane wrote:
> * The commented-out tests in 001_ssltests.pl contained hard-wired
> expectations as to certificate serial numbers, which are obsolete now.
> I just replaced them with "\d+", but if anyone feels like that's not
> good enough, we could continue to c
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:
>
On Thu, Apr 17, 2025 at 8:20 AM Tom Lane wrote:
> I confirm this silences those warnings on my Fedora 41 box.
Instead of doing
lex = calloc(...);
/* (error out on NULL return) */
makeJsonLexContextCstringLen(lex, ...);
we need to do
lex = makeJsonLexContextCstringLen(NULL, ...)
On Wed, Apr 16, 2025 at 4:04 PM Tom Lane wrote:
> Looking through all of the callers of freeJsonLexContext, quite
> a lot of them use local JsonLexContext structs, and probably some
> of them are more performance-critical than these. So that raises
> the question of why are we seeing warnings for
On Tue, Apr 15, 2025 at 3:25 PM Jelte Fennema-Nio wrote:
> I don't understand why it should be a server option instead of a user
> mapping option. Having it be a server option means that *any* Postgres
> user can read its contents.
Thank you for saying something; I'd hallucinated that srvoptions
On Tue, Apr 15, 2025 at 1:48 PM Noah Misch wrote:
> If we think oauth_client_secret should get dispchar="*" UI treatment yet be a
> postgres_fdw server option, postgres_fdw code can make it so. postgres_fdw
> already has explicit code to reclassify the "user" option.
Agreed, I will add an open i
On Tue, Apr 15, 2025 at 12:14 PM Noah Misch wrote:
> I suspect this should use .dispchar="*" to encourage UIs to display
> oauth_client_secret like a password field. Thoughts?
Hmm, from a UI perspective I agree. (The builtin flow targets "public
clients", where secrets are discouraged and/or und
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: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 ahea
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 doc
On Mon, Apr 14, 2025 at 1:16 PM Daniel Gustafsson wrote:
> Just to close the loop, this was done yesterday as 2970c75dd982.
Thanks!
--Jacob
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
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
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 Wed, Apr 9, 2025 at 4:48 AM Daniel Gustafsson wrote:
> -extern const pg_be_sasl_mech pg_be_oauth_mech;
> +extern PGDLLIMPORT const pg_be_sasl_mech pg_be_oauth_mech;
> +1 on this.
LGTM, too.
Thanks!
--Jacob
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
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.
> Maybe it would also make sense to make libpq-oauth a subdirectory of the
> libpq directory instead of a peer.
Works for me.
On Mon, Apr 7, 2025 at 7:21 AM Andres Freund wrote:
> On 2025-04-04 17:27:46 -0700, Jacob Champion wrote:
> > +This module ABI is an internal implementat
On Thu, Apr 10, 2025 at 7:41 AM Dave Cramer wrote:
> Done in new patch attached
I think this patch splices a sentence:
> + not equal to the version the server supports.
> message.
+1 for clarifying the message description; it has vaguely bothered me
for a while [1]. :)
--Jaco
1 - 100 of 1140 matches
Mail list logo
