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
>
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 |