Re: quoting psql varible as identifier - Mailing list pgsql-hackers
From | Pavel Stehule |
---|---|
Subject | Re: quoting psql varible as identifier |
Date | |
Msg-id | 162867791001190954p418b5b9fl2f94cef279d17707@mail.gmail.com Whole thread Raw |
In response to | Re: quoting psql varible as identifier (Robert Haas <robertmhaas@gmail.com>) |
Responses |
Re: quoting psql varible as identifier
|
List | pgsql-hackers |
2010/1/19 Robert Haas <robertmhaas@gmail.com>: > On Tue, Jan 19, 2010 at 4:13 AM, Pavel Stehule <pavel.stehule@gmail.com> wrote: >> 2010/1/18 Robert Haas <robertmhaas@gmail.com>: >>> On Mon, Jan 18, 2010 at 3:26 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: >>>> Robert Haas <robertmhaas@gmail.com> writes: >>>>> ... Also, I prefer an >>>>> API where the escaping function does include the quotes, so I've done >>>>> it that way in the attached patch. >>>> >>>> IMO this function should act as much like PQescapeStringConn as possible. >>> >>> Generally speaking, I agree... >>> >>>> Random differences like including or not including outer quotes don't >>>> make the user's life better. Random differences like a slightly >>>> different rule for the amount of space required are outright dangerous. >>> >>> I'm not sure that not including the quotes is any better. If someone >>> escapes foo and gets back foo, are they going to realize that escaping >>> fo"o is going to give them back fo""o rather than "fo""o"? One >>> difference vs. PQescapeStringConn() is that if you fail to include the >>> surrounding quotes in that case, something will almost certainly break >>> in a noisy and highly visible fashion. Here that might not happen, or >>> someone might call one of PQescapeStringConn() and >>> PQescapeIdentifierConn() and then use the wrong sort of outer quotes. >>> >>> IMO, it's actually pretty weird that PQescapeStringConn() and >>> quote_literal() are named differently and do incompatible things. I >>> think it would be a plus if this new function were a little more >>> similar to quote_ident(), but that's just MHO, of course. >>> >> >> I am afraid so we can do nothing now with this. There are two >> arguments - consistency versus robustness. If you use >> PQescapeStringConn() without outer quotes, then you have a SQL >> injection problem (there could not be error) :(. When there are no >> escape function that add outer quotes, then can be strange for >> developers working with one different. >> >> I see three solution: >> >> a) use a PQescapeIdentifConn as PQescapeStringConn, >> b) move this functionality to psql without change of API, >> c) change semantic and name - maybe PQquoteIdentifierConn() >> >> Personally I am for a) and later for b). What I know - php coders >> needs some secure function for identifier escaping - but I dislike PHP >> because every function is designed different. > > I think what you're saying is that you agree with Tom's position that > the new escaping function should not add the necessary surrounding > quotes, instead leaving that to the user. Is that correct? yes Pavel > > ...Robert >
pgsql-hackers by date: