Robert Haas <robertmh...@gmail.com> writes:
> ... I think as
> long as we're adding a new function, we should make it behave sanely.
> We could even take the opportunity to go back and add a saner version
> of PQescapeStringConn.
Well, it's a bit late in the devel cycle to be inventing from scratch,
but if we did want to do something "saner" what would it look like?
I can see the following possibilities:
* include boundary quotes (and E too in the literal case). This would
imply telling people they should leave whitespace around the value in
the constructed query ... or should we insert leading/trailing spaces
to prevent that mistake too?
* malloc our own result value instead of expecting caller to provide
space. This adds another failure case (out of memory) but it's not
really much different from OOM on the caller side.
* anything else you want to change?
I suggest we could use PQescapeLiteral + PQescapeIdentifier as names
if we provide a new pair of functions defined with a different API.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
