Tatsuo Ishii <ishii@sraoss.co.jp> writes:
> I suggest that PQescapeString() should have a parameter to specify the
> encoding of "to".
You mean the encoding of "from", no? But actually I'd argue that
letting the client programmer supply the encoding is still a pretty
dangerous practice. Your example demonstrates that if the encoding
PQescapeString is told is different from the encoding the backend parser
thinks is in use, problems result. Perhaps we should pass the PGconn
to new-PQescapeString and let it dig the client encoding out of that.
You could still get burnt if the client encoding changes between the
invocation of new-PQescapeString and the sending of the constructed
command, but that's a fairly unlikely case.
The bottom line to this though is that these encodings are just plain
dangerous. I'm more than half tempted to suggest that the only secure
answer is to drop support for these encodings. Consider for example
an application that isn't using PQescapeString but has its own
double-backslashes-and-quotes logic embedded. You can break it if you
can manage to get the backend to think that the client encoding is SJIS
or similar. That's a hazard we're basically not ever going to be able
to prevent.
regards, tom lane
