Re: quoting psql varible as identifier

From: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Alvaro Herrera <alvherre(at)commandprompt(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: quoting psql varible as identifier
Date: 2010-01-19 09:13:38
Message-ID: 162867791001190113x1d5f93c0m264909be0c112f15@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

2010/1/18 Robert Haas <robertmhaas(at)gmail(dot)com>:
> On Mon, Jan 18, 2010 at 3:26 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Robert Haas <robertmhaas(at)gmail(dot)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
>

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Kurt Harriman 2010-01-19 09:29:11 Re: Patch: Remove gcc dependency in definition of inline functions
Previous Message Magnus Hagander 2010-01-19 08:44:01 Re: mailing list archiver chewing patches