Re: Negative Integers Escaping

Поиск
Список
Период
Сортировка
От A.M.
Тема Re: Negative Integers Escaping
Дата
Msg-id 42F3A04F-0C64-4041-B631-E757C564CAB9@themactionfaction.com
обсуждение исходный текст
Ответ на Re: Negative Integers Escaping  (Daniele Varrazzo <daniele.varrazzo@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: Daniele Varrazzo
Дата:
Сообщение: Deadlock
Следующее
От: Federico Di Gregorio
Дата:
Сообщение: Re: Negative Integers Escaping