On Wed, Jun 12, 2024 at 7:34 PM Alexander Korotkov <aekorot...@gmail.com> wrote: > On Wed, Jun 12, 2024 at 7:08 PM Jelte Fennema-Nio <postg...@jeltef.nl> wrote: > > On Wed, 12 Jun 2024 at 17:50, Andres Freund <and...@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
