Re: Negative Integers Escaping

On May 27, 2011, at 7:45 PM, Daniele Varrazzo wrote:

> On Fri, May 27, 2011 at 8:03 PM, Maxim Avanov <maxim(dot)avanov(at)gmail(dot)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. With a real out-of-band parameter system, the above example will not PREPARE/parse. I am strong proponent for the real parameter system (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