> 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?
Oops, "from", yes.
> 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.
Sound good to pass PGconn to new-PQescapeString. Here is the proposed
calling sequence for the new function:
size_t PQescapeStringWithConn (const PGconn *conn, char *to, const char *from, size_t length)
If this is ok, I will implement for 8.2.
> 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.
Dropping support for SJIS and so on will not be practical at all since
these encodings has been widely used and I don't see these encodings
are deprecated in the near future. I think dropping the support will
simply prevent people from using PostgreSQL. Especially in Windows
world, these encodings are pretty common.
I know that these encodings are broken in their design and actually I
hate them:-) But this is real world and we have to live with them...
--
Tatsuo Ishii
SRA OSS, Inc. Japan