Re: psycopg3 and adaptation choices

On Mon, 9 Nov 2020 at 02:19, Vladimir Ryabtsev <greatvovan@gmail.com> 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 server-side parameter binding may want to give some new
impression.
> Moreover, it appears more convenient when you have parameters numbered and can reuse them a few times in a query.

Hi Vladmir,

I wouldn't want to step away from the %s placeholder, because that
would mean that every query of every program written in psycopg2 would
need to be rewritten, and that would be an impossibly steep adoption
curve. Furthermore the %(named)s placeholders are a much better
convenience over $n: you couldn't pass {name: param} mapping
otherwise.

The $n parameters are also cumbersome in requiring an explicit
mapping, where an implicit one would have worked (so it has to be "$1
$2 $3" and counting, instead of uniform "%s, %s, %s") and slipping a
parameter in the middle of a sequence of parameters requires to
renumber all the following ones.

Another feature added to psycopg3 is support for binary parameters: I
added %b and %(name)b placeholders to mark the placeholders requiring
a binary param, so that you can `execute("insert into image (name,
data) values (%s, %b)", [filename, image_bytes])`: if you used $n
placeholders you would need a new parameter to specify, of the list
(or mapping) of parameters, which one do you want in text and in
binary format, or some other mechanism, such as a
`Binary(image_bytes)` wrapper.

Said that, because we are using the server-side binding, we are
actually passing $n parameters to the server: in psycopg3 there is a
parser to convert %s and %(name)s placeholders to $n style and to
reorder params mapping when needed. So the query above results in a
call like `pgconn.exec_params(b"select $1, $2", [filename.encode(...),
image_bytes], [TEXT, BINARY])`. 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"), [...])` or some other wrapping
mechanism.

-- Daniele