Skip site navigation (1) Skip section navigation (2)

Re: Negative Integers Escaping

From: "A(dot)M(dot)" <agentm(at)themactionfaction(dot)com>
To: psycopg(at)postgresql(dot)org
Subject: Re: Negative Integers Escaping
Date: 2011-05-28 01:52:09
Message-ID: 42F3A04F-0C64-4041-B631-E757C564CAB9@themactionfaction.com (view raw or flat)
Thread:
Lists: psycopg
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

In response to

psycopg by date

Next:From: Federico Di GregorioDate: 2011-05-29 20:04:02
Subject: Re: Negative Integers Escaping
Previous:From: Daniele VarrazzoDate: 2011-05-28 00:12:59
Subject: Deadlock

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group