Re: RFC: adding pytest as a supported test framework

From: Alexander Korotkov <aekorotkov(at)gmail(dot)com>
To: Jelte Fennema-Nio <postgres(at)jeltef(dot)nl>
Cc: Andres Freund <andres(at)anarazel(dot)de>, Jacob Champion <jacob(dot)champion(at)enterprisedb(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: RFC: adding pytest as a supported test framework
Date: 2024-06-12 17:11:55
Message-ID: CAPpHfdt=DRk_xyvoe2VtR9X0uriqAgfCd+R6pU8ovXFOt1VdVA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Jun 12, 2024 at 7:34 PM Alexander Korotkov <aekorotkov(at)gmail(dot)com> wrote:
> On Wed, Jun 12, 2024 at 7:08 PM Jelte Fennema-Nio <postgres(at)jeltef(dot)nl> wrote:
> > On Wed, 12 Jun 2024 at 17:50, Andres Freund <andres(at)anarazel(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Igor V.Gnatyuk 2024-06-12 17:13:19 Multi-transactional statements and statistics for autovacuum
Previous Message Peter Geoghegan 2024-06-12 17:04:59 Re: Revive num_dead_tuples column of pg_stat_progress_vacuum