> 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 Tue, 10 Nov 2020 at 03:22, Christophe Pettus <xof@thebuild.com> wrote:
>
> > On Nov 9, 2020, at 19:20, Daniele Varrazzo <daniele.varrazzo@gmail.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
