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

From Pavel Stehule
Subject Re: quoting psql varible as identifier
Date
Msg-id 162867791001190113x1d5f93c0m264909be0c112f15@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/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.

regards
Pavel


>> Also, why is this patch changing the documentation of PQescapeStringConn?
>> It might be only whitespace changes, but I don't particularly wish to
>> have to determine that.
>
> See previous discussion upthread.
>
> http://archives.postgresql.org/pgsql-hackers/2010-01/msg01516.php
>
> ...Robert
>


pgsql-hackers by date:

Previous
From: Magnus Hagander
Date:
Subject: Re: mailing list archiver chewing patches
Next
From: Kurt Harriman
Date:
Subject: Re: Patch: Remove gcc dependency in definition of inline functions