Re: psycopg3 and adaptation choices

> I've added comparison tables with the choices available.

Nice article!

I see you have assigned weights to the upsides and downsides
and now these weights are going to determine the winner.
My particular question is regarding '-2' score for mapping numbers
to 'unknown'.

Why do you consider it such an important use-case? In my opinion,
such usage is just waste of resources and traffic, and if presenting
some constants in the result set is really required, other means,
such as 'SQL.format()`, might be a better option.

> Is it absurd to make the choice at execution time, based on the actual
value of the Python int?

If I got the idea correctly, it may lead to some inconsistent behaviour
in a series of executions of a prepared statement. Imagine you tested
you query with small numbers that fit into int4, but in production rarely
blogger values can come that must be sent as int8, which will lead to
occasional cast errors.

Vladimir

On Mon, 9 Nov 2020 at 19:43, 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...
>
> -- Daniele
>