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