On Wed, Apr 23, 2025 at 2:11 AM Jelte Fennema-Nio <postgres@jeltef.nl> 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 small size of the scripts, I expect that
> it'd be extremely rare for us to backport changes to them. e.g. I
> doubt your oauth server would need many changes to keep working
> correctly for the lifetime of PG18. Maybe it gets some minor fixes in
> 18.1 and/or 18.2 but other than that it seems really unlikely.
That assumes there are no bugs in my code to backport tests for, and I
don't like assuming that. The Perl and Python sides of the
oauth_validator tests are pretty tightly coupled out of necessity.
On Wed, Apr 23, 2025 at 7:54 AM Jelte Fennema-Nio <postgres@jeltef.nl> wrote:
> I don't really think this would be required to bump Postgres its
> minimum supported postgres version. psycopg is a client and postgresql
> is the server, it seems fine for them to use different Python
> versions. The postgresql-server package could depend on python3.9,
> while psycopg packages would happily use python3.6.
I'm not sure that's the mental model we would want, since clients can
be used server-side. Maybe a safer way to split, if and when we want
to decouple this on RHEL, would be between clients of only the Python
language (tests), and clients of the Python ABI (PL/Python, psycopg,
etc.). Like, imagine a world where backported tests could use new
goodies, but extensions remained solidly on platform defaults. That
seems kind of nice to me, at a surface level.
The Python stable ABI may change the calculus, too, but I'm not going
to look into that right now...
--Jacob
