On Mon, Jan 18, 2010 at 3:26 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Robert Haas <robertmh...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
