On 10/11/20, Daniele Varrazzo (daniele.varra...@gmail.com) wrote:
> On Tue, 10 Nov 2020 at 03:22, Christophe Pettus wrote:
> >
> > > On Nov 9, 2020, at 19:20, Daniele Varrazzo
> > > wrote:
> > >
> > >Choices to cast Python ``int`` type:
> >
> > Is it absurd to make the choice at execution ti
> 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,
I am sometimes round-tripping magic constants to tell which part of a, say,
UNION actual
> 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 s
On Tue, 10 Nov 2020 at 03:22, Christophe Pettus wrote:
>
> > On Nov 9, 2020, at 19:20, Daniele Varrazzo
> > 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 abou
On Tue, 10 Nov 2020 at 03:20, Christophe Pettus wrote:
>
> I don't want to derail this, but a question: Can a connection be set to use
> the simple-query protocol instead of the extended-query protocol in 3?
It won't be set explicitly to use simple/extended protocol, but if a
query is passed wit
> On Nov 9, 2020, at 19:20, Daniele Varrazzo 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?
--
-- Christophe Pettus
x...@thebuild.com
On Tue, 10 Nov 2020 at 01:06, Vladimir Ryabtsev wrote:
> May I ask you again about using 'unknown' for numbers? Could you recap
> all the downsides of this approach?
After this useful conversation, I've updated the article
(https://www.varrazzo.com/blog/2020/11/07/psycopg3-adaptation/) and
I've
> On Nov 7, 2020, at 08:32, Daniele Varrazzo wrote:
> What do you think?
I don't want to derail this, but a question: Can a connection be set to use the
simple-query protocol instead of the extended-query protocol in 3?
--
-- Christophe Pettus
x...@thebuild.com
On Tue, 10 Nov 2020 at 01:19, Adrian Klaver wrote:
>
> On 11/8/20 2:21 PM, Daniele Varrazzo wrote:
> > 1. If we specify `numeric` or `int8` as oid, inserting in an int field
> > in a table will work ok, but some functions/operators won't (e.g. "1
> > > %s").
>
> What is not working here?
Postgre
On 11/8/20 2:21 PM, Daniele Varrazzo wrote:
On Sun, 8 Nov 2020 at 20:35, Adrian Klaver wrote:
Alright I understand now.
More below.
In psycopg3 the idea is to use a more advanced protocol, which
separates query and parameters. It brings several benefits: can use
prepared statements (send a
> I wouldn't want to step away from the %s placeholder ...
Thanks for the elaboration, I agree with your argumentation.
> If there is interest we can think about how to make this querying layer
> more accessible (e.g. using a `cur.execute(PgQuery("select $1, $2"),
[...])`
It's always good if suc
On 09/11/20 13:00, Daniele Varrazzo wrote:
On Mon, 9 Nov 2020 at 06:57, Federico Di Gregorio wrote:
[snip]
IMHO, oid is a bad idea
because it has a very specific semantic and the error messages generated
by PostgreSQL will be more confusing.
I'm not sure I understand this. At the moment, the
On Mon, 9 Nov 2020 at 06:57, Federico Di Gregorio wrote:
> In your example I'd just go for int8 (the largest possible int in
> PostgreSQL). Decimal would probably be better (largest range) but it is
> not what the majority of people would expect.
The problem with int8 is that it fails in all the
On Mon, 9 Nov 2020 at 02:49, Vladimir Ryabtsev wrote:
>
> A wild idea: support both client-side (like in psycopg2) and server-side
> binding. Keep old '%s' syntax and provide a separate method for client-side
> binding (not in 'cur.execute()'). This could alleviate cases like parameters
> round
On Mon, 9 Nov 2020 at 02:19, Vladimir Ryabtsev wrote:
> BTW, may I ask another question regarding parameters?
> Don't you want to step away from '%s' syntax and use '$1, $2, ...' which
> seems to be more traditional in the database world?
> '%s' feels like old-school string formatting, new serve
On 08/11/20 23:21, Daniele Varrazzo wrote:
[snip]
1. If we specify `numeric` or `int8` as oid, inserting in an int field
in a table will work ok, but some functions/operators won't (e.g. "1
%s").
2. If we specify `int4` it would work for those few functions defined
as `integer`, but if we try t
A wild idea: support both client-side (like in psycopg2) and server-side
binding. Keep old '%s' syntax and provide a separate method for client-side
binding (not in 'cur.execute()'). This could alleviate cases like
parameters roundtripping and other cases of safe query composition. At
the same time
Hello,
>From what I understood from your messages, I like passing 'unknown' for
both strings and numbers.
Roundtripping parameters seems to be a less common case (with a possible
fix if it's necessary).
Is there anything else that does not work or works counterintuitively with
Python 'int' -> 'unk
On Sun, 8 Nov 2020 at 20:35, Adrian Klaver wrote:
> Alright I understand now.
> More below.
>
> >
> > In psycopg3 the idea is to use a more advanced protocol, which
> > separates query and parameters. It brings several benefits: can use
> > prepared statements (send a query once, several paramete
On 11/8/20 11:16 AM, Daniele Varrazzo wrote:
On Sun, 8 Nov 2020 at 18:43, Adrian Klaver wrote:
If I'm following correctly in psycopg2 the adapter does type adaption on
the client side and passes that to server with oid for processing. In
psycopg3 you are proposing to let the server do more of
On Sun, 8 Nov 2020 at 18:43, Adrian Klaver wrote:
> If I'm following correctly in psycopg2 the adapter does type adaption on
> the client side and passes that to server with oid for processing. In
> psycopg3 you are proposing to let the server do more of the type
> adaption and to that end you ar
On 11/7/20 8:32 AM, Daniele Varrazzo wrote:
Hello,
As you may know I'm implementing a new psycopg version using
server-side argument binding. As a real-time test I'm writing a Django
backend for it, and running Django test suite. This has uncovered
unexpected behaviours caused by the different w
22 matches
Mail list logo
