Re: Negative Integers Escaping
От
Daniele Varrazzo
Тема
Re: Negative Integers Escaping
Дата
Msg-id
BANLkTi=nhPrC3wAC4E=_2opPxysaEfCf3Q@mail.gmail.com
Ответ на
Re: Negative Integers Escaping (Marko Kreen)
Список
Дерево обсуждения
Negative Integers Escaping Maxim Avanov <maxim.avanov@gmail.com>
Re: Negative Integers Escaping Oswaldo <listas@soft-com.es>
Re: Negative Integers Escaping Maxim Avanov <maxim.avanov@gmail.com>
Re: Negative Integers Escaping Daniele Varrazzo <daniele.varrazzo@gmail.com>
Re: Negative Integers Escaping "A.M." <agentm@themactionfaction.com>
Re: Negative Integers Escaping Federico Di Gregorio <federico.digregorio@dndg.it>
Re: Negative Integers Escaping Daniele Varrazzo <daniele.varrazzo@gmail.com>
Re: Negative Integers Escaping Marko Kreen <markokr@gmail.com>
Re: Negative Integers Escaping Daniele Varrazzo <daniele.varrazzo@gmail.com>
Re: Negative Integers Escaping Federico Di Gregorio <federico.digregorio@dndg.it>
On Tue, May 31, 2011 at 12:47 PM, Marko Kreen wrote: > And the proper fix is quite well-known: $x placeholders > and Extended Query protocol. Do you have ideas about how to avoid breaking applications where people have used multiple queries in an execute? Or how to pass arrays in a robust way when the suggested method (ARRAY[] construct) doesn't work with PQexecParams? Or to make IN work? I've already called for discussion a couple of months ago [1] about supporting the EQ protocol: it will eventually be done, but the result will hardly be a complete replacement for what psycopg currently does, so don't see it becoming the default escape mechanism. (Of course, while I'm positive about its implementation, nobody has stepped ahead for implementing it, so I'm afraid it will have to wait for a slice of my Copious Spare Time). While it's good stuff the EQ exists for applications directly using the libpq, It wouldn't have saved many troubles for psycopg: IMO this one is really borderline to a pathological case and is not a security issue. If there was a psycopg3 to be written with no backward compatibility to maintain, the EQ protocol would be a reasonable choice. Of course it wouldn't offer the above features, no mogrify(), no cursor.query and so on, but that would be tolerable for a new driver with a different features set. But just putting EQ into psycopg2 simply means dropping features and causing problems to a random bunch of users: I don't see dropping such features just to use the EQ a victory overall. -- Daniele [1] http://archives.postgresql.org/psycopg/2011-02/msg00076.php
В списке psycopg по дате отправления