Re: quoting psql varible as identifier - Mailing list pgsql-hackers

From Robert Haas
Subject Re: quoting psql varible as identifier
Date
Msg-id 603c8f071001190948s38d1213ahfa81b30ab0e15450@mail.gmail.com
Whole thread Raw
In response to Re: quoting psql varible as identifier  (Pavel Stehule <pavel.stehule@gmail.com>)
Responses Re: quoting psql varible as identifier  (Pavel Stehule <pavel.stehule@gmail.com>)
List pgsql-hackers
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?

...Robert


pgsql-hackers by date:

Previous
From: Boszormenyi Zoltan
Date:
Subject: Re: ECPG patch 4.1, out-of-scope cursor support in native mode
Next
From: Pavel Stehule
Date:
Subject: Re: quoting psql varible as identifier