From: | Daniele Varrazzo <daniele(dot)varrazzo(at)gmail(dot)com> |
---|---|
To: | Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)com> |
Cc: | "psycopg(at)postgresql(dot)org" <psycopg(at)postgresql(dot)org> |
Subject: | Re: Solving the SQL composition problem |
Date: | 2017-01-03 16:40:57 |
Message-ID: | CA+mi_8aTWKpMfkfez=yKQyWP0Rw72cncJ8MZ9pdcCT6QYuug8w@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | psycopg |
On Tue, Jan 3, 2017 at 5:24 PM, Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)com> wrote:
> What I'm suggesting is to let Postgres handle the replacement of normal
> values, using the prepared statement syntax of $1, $2, etc[1], and only do
> identifier replacement in python (using quote_ident). That means a lot less
> time spent parsing, and opens the door for eventually doing more efficient
> stuff over the wire, like using binary type formats.
>
> 1: https://www.postgresql.org/docs/current/static/sql-prepare.html
Hi Jim,
this is a very desirable feature. However it would be a major source
of backward incompatibility. Even keeping the placeholders as %s or
%(name)s some query would stop working because of different postgresql
cast rules and because PQexecParams doesn't support passing several
semicolon-separated statements at once. We will eventually get there
in another major release of the adapter. Adrian has already posted a
link with further discussion about the topic.
-- Daniele
From | Date | Subject | |
---|---|---|---|
Next Message | Jim Nasby | 2017-01-04 00:03:35 | Re: Solving the SQL composition problem |
Previous Message | Adrian Klaver | 2017-01-03 16:35:50 | Re: Solving the SQL composition problem |