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  (Robert Haas <robertmhaas@gmail.com>)
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:

Previous
From: Robert Haas
Date:
Subject: Re: quoting psql varible as identifier
Next
From: "Kevin Grittner"
Date:
Subject: Re: Git out of sync vs. CVS