On Wed, Jun 12, 2024 at 7:34 PM Alexander Korotkov <aekorotkov@gmail.com> wrote:
> On Wed, Jun 12, 2024 at 7:08 PM Jelte Fennema-Nio <postgres@jeltef.nl> wrote:
> > On Wed, 12 Jun 2024 at 17:50, Andres Freund <andres@anarazel.de> wrote:
> > > > The OAuth pytest suite makes extensive use of
> > > > - psycopg, to easily drive libpq;
> > >
> > > That's probably not going to fly. It introduces painful circular dependencies
> > > between building postgres (for libpq), building psycopg (requiring libpq) and
> > > testing postgres (requiring psycopg).
> > >
> > > You *can* solve such issues, but we've debated that in the past, and I doubt
> > > we'll find agreement on the awkwardness it introduces.
> >
> > psycopg has a few implementations binary, c, & pure python. The pure
> > python one can be linked to a specific libpq.so file at runtime[1]. As
> > long as we don't break the libpq API (which we shouldn't), we can just
> > point it to the libpq compiled by meson/make. We wouldn't be able to
> > use the newest libpq features that way (because psycopg wouldn't know
> > about them), but that seems totally fine for most usages (i.e. sending
> > a query over a connection). If we really want to use those from the
> > python tests we could write our own tiny CFFI layer specifically for
> > those.
>
> I guess you mean pg8000. Note that pg8000 and psycopg2 have some
> differences in interpretation of datatypes (AFAIR arrays, jsonb...).
> So, it would be easier to chose one particular driver. However, with
> a bit efforts it's possible to make all the code driver agnostic.
Ops, this is probably outdated due to presence of psycopg3, as pointed
by Daniele Varrazzo [1].
Links.
1. https://www.postgresql.org/message-id/CA%2Bmi_8Zj0gpzPKUEcEx2mPOAsm0zPvznhbcnQDA_eeHVnVqg9Q%40mail.gmail.com
------
Regards,
Alexander Korotkov
Supabase