This is already settled but wanted to follow through on one point..

On Fri, Jan 04, 2019 at 07:42:28PM +0100, Christoph Zwerschke wrote:
> > Currently it calls PQexecParams which (I think you agree) is creating
> > unnamed prepared statements behind the scenes.
> 
> Yes, I think this is the case. And I got the impression that even simple
> PQexecs annihilate existing unnamed statements. Did you also see that?

I *hadn't* seen that since my initial implementation didn't allow for unnamed
prepared statements, since it only used SQL PREPARE, not library PQprepare, so
was always named (try as I might I cannot see how to pass a null string to SQL
command).

I used pygres HEAD and it immediately broke;
|db.prepare('', s)
|db.query('begin')
=> pg.OperationalError: ERROR:  unnamed prepared statement does not exist

|db.prepare('', s)
|db.query_formatted('SELECT %s', [1])
=> pg.DatabaseError: ERROR:  bind message supplies 10 parameters, but prepared 
statement "" requires 1

|db.prepare('', s)
|db.query_formatted('SELECT %s,%s', [1,2])
=> pg.DatabaseError: ERROR:  bind message supplies 10 parameters, but prepared 
statement "" requires 2

Which is what the protocol docs say

"The simple Query message is approximately equivalent to the series Parse,
Bind, portal Describe, Execute, Close, Sync, using the unnamed prepared
statement and portal objects and no parameters."

BTW, this neatly allows search CSV logs for unparameterized(unsanitized)
queries (except that queries with no parameters also show up as "statement:")

postgres=# SELECT left(message,199), COUNT(1) FROM postgres_log_2019_01_05_0100 
WHERE message LIKE 'statement:%' AND message~'[0-9]|''[^'']' GROUP BY 1 ORDER 
BY 2 DESC LIMIT 9;
...
   324 | statement: SELECT site_id from sites where site_office = 'xxxx_GGSN_1' 
AND site_location='mms.xxxxxxxxx.com'

postgres=# SELECT COUNT(1) ,split_part(message, ':', 1) FROM 
postgres_log_2019_01_05_0100 GROUP BY 2 ORDER BY 1 DESC LIMIT 2;
 count  |    split_part     
--------+------------------
 141083 | execute <unnamed>
  43627 | statement

Justin
_______________________________________________
PyGreSQL mailing list
PyGreSQL@Vex.Net
https://mail.vex.net/mailman/listinfo/pygresql

Reply via email to