From: | Rory Campbell-Lange <rory(at)campbell-lange(dot)net> |
---|---|
To: | Daniele Varrazzo <daniele(dot)varrazzo(at)gmail(dot)com> |
Cc: | Christophe Pettus <xof(at)thebuild(dot)com>, Vladimir Ryabtsev <greatvovan(at)gmail(dot)com>, Federico Di Gregorio <fog(at)dndg(dot)it>, psycopg(at)lists(dot)postgresql(dot)org |
Subject: | Re: psycopg3 and adaptation choices |
Date: | 2020-11-10 21:24:11 |
Message-ID: | 20201110212411.GA5668@campbell-lange.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | psycopg |
On 10/11/20, Daniele Varrazzo (daniele(dot)varrazzo(at)gmail(dot)com) wrote:
> On Tue, 10 Nov 2020 at 03:22, Christophe Pettus <xof(at)thebuild(dot)com> wrote:
> >
> > > On Nov 9, 2020, at 19:20, Daniele Varrazzo <daniele(dot)varrazzo(at)gmail(dot)com> wrote:
> > >
> > > Choices to cast Python ``int`` type:
> >
> > Is it absurd to make the choice at execution time, based on the actual value of the Python int?
>
> I've been thinking a lot about it. I haven't completely ruled it out,
> but there are a few cases in which having different oids for the same
> query gets in the way. One that comes to mind is with prepared
> statements, either explicit (which I haven't exposed yet, but it's
> like the #1 request for a new feature), or implicit (currently using
> them to implement 'executemany()'). However I might be overestimating
> these issues, yes.
>
> I guess I should give an overview of the whole adaptation system: I'll
> try and write its documentation in the next few days. I have to start
> with the documentation somewhere...
Apologies for a no-doubt naive suggestion, Daniele, but how about a
postgresql type 'shim' of some sort that only accepts python types on
input and translates output back to only python types.
If such a shim, perhaps a type + C function pair were used, I assume it
would not round-trip per-se, but could cycle through int types from most
restrictive to most lenient on the basis (I'm guessing) that postgresql
will coerce a postgres int4 to and int8 on insertion if necessary, on
the principle that the following works ok:
test=> create table a (b int8);
CREATE TABLE
test=> insert into a values (1::int4);
INSERT 0 1
test=> create table b (c numeric);
CREATE TABLE
test=> insert into b values (4::int8);
INSERT 0 1
I assume mapping native postgresql column types to output values would
pass back through such a 'sieve' quite naturally into native python
types.
Whether such a filtering layer should work directly in postgresql or as
a translation (or 'adaptation') layer in psycopg[3]*is perhaps a similar
debate -- although at a lower level -- about Django's ORM. Where should
the logic lie?
By the way I believe this is this 'layer' for the golang pgx module,
which may be of interest:
https://github.com/jackc/pgx/blob/93c6b60429e13e0016665214dca2c6382982cf99/values.go#L28
although golang is of course is more strongly typed than python. I
thought the type switch test for coercion, as Christophe suggests, might
be doable through the 'shim' layer I'm imagining.
Regards
Rory
From | Date | Subject | |
---|---|---|---|
Next Message | Vladimir Ryabtsev | 2020-11-10 21:59:31 | Using composite types in psycopg3 |
Previous Message | Karsten Hilbert | 2020-11-10 19:23:41 | Aw: Re: psycopg3 and adaptation choices |