Re: Negative Integers Escaping - Mailing list psycopg

From A.M.
Subject Re: Negative Integers Escaping
Date
Msg-id 42F3A04F-0C64-4041-B631-E757C564CAB9@themactionfaction.com
Whole thread Raw
In response to Re: Negative Integers Escaping  (Daniele Varrazzo <daniele.varrazzo@gmail.com>)
List psycopg
On May 27, 2011, at 7:45 PM, Daniele Varrazzo wrote:

> On Fri, May 27, 2011 at 8:03 PM, Maxim Avanov <maxim.avanov@gmail.com> wrote:
>> Hi, Oswoldo. Thanks for reply.
>>> Is a good rule to always put spaces between operators
>>
>> I agree. It's a good rule but it's neither in SQL nor in Postrges syntax
>> rules. And psycopg should guarantee a valid escaping of parameters according
>> to all possible and valid syntax rules.
>
> There's plenty of space for creating pathological commands. Do you
> want another one?
>
> "select * from blah limit%s"
>
> I think in general sticking characters in front of placeholders you
> don't know how will get filled is not a robust way to write your sql
> string.
>
> I'm -1 about complicating the escaping of simple values just to
> accommodate artificial problems: fixing this one IMO wouldn't justify
> the potential problems of backward incompatibilities that may arise.

This only holds if one considers SQL parameters are components to concatenate into the string as psycopg does it today.
Witha real out-of-band parameter system, the above example will not PREPARE/parse. I am strong proponent for the real
parametersystem (which every other postgresql interface (even pg8000) already supports). 

agentm=# PREPARE test(int) AS SELECT$1;
ERROR:  syntax error at or near "SELECT$1" at character 22
STATEMENT:  PREPARE test(int) AS SELECT$1;
ERROR:  syntax error at or near "SELECT$1"
LINE 1: PREPARE test(int) AS SELECT$1;


Cheers,
M

psycopg by date:

Previous
From: Daniele Varrazzo
Date:
Subject: Deadlock
Next
From: Federico Di Gregorio
Date:
Subject: Re: Negative Integers Escaping