Re: Negative Integers Escaping
От | Marko Kreen |
---|---|
Тема | Re: Negative Integers Escaping |
Дата | |
Msg-id | BANLkTikxaDk40r1N2+Cf0PW0gqx4JQE44w@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Negative Integers Escaping (Federico Di Gregorio <federico.digregorio@dndg.it>) |
Ответы |
Re: Negative Integers Escaping
|
Список | psycopg |
On Sun, May 29, 2011 at 11:04 PM, Federico Di Gregorio <federico.digregorio@dndg.it> wrote: > On 28/05/11 01:45, 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. > > Sorry, but I don't agree. SQL rules explicitly say that LIMITX is > invalid for any X because LIMIT should be separated from its argument by > white space; so you're writing incorrect SQL from the start. > > A mathematical expression doesn't need, at least in SQL, any whitespace > so, writing colname-%s is *correct* and the programmer is correct when > expects the DB adapter to quote the arguments to make sure they don't > introduce any new errors in SQL. And the proper fix is quite well-known: $x placeholders and Extended Query protocol. Any other kind of query massaging seems inappropriate. -- marko
В списке psycopg по дате отправления: