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
12 matches
Mail list logo
