On Fri, 9 May 2008, Greg Sabino Mullane wrote:
No, we can't leave backslashes unescaped: that's a compatiblity can of
worms I don't want to open. Consider the result of a $dbh->quote()
that's stored by the app and then reused - but with a different SCS
setting!
That seems like something that Shouldn't Be Done. $dbh->quote() is a
contextual operation anyway that depends on the database handle in
question, and as discussed here, possibly the particular connection. It
seems it should be documented that quote()d strings should not be
stored; strings should be quoted immediately before being used.
Well, I've not heard of anyone actually doing that, but never
underestimate the ability of people to misuse the tools they have in
strange and interesting ways. To be fair, up until now, the output has
been completely consistent across all connections and versions.
Certainly. And I presume few will read upgrade notes ...
But what is the alternative? Escaping a backslash is simply wrong in an
E''-quoted string, so we have to consider the SCS and non-SCS quote-reuse
scenario anyway, don't we? I guess you're thinking it should fail safe,
and I guess it does, but failing with extra \ is pretty ugly and does mess
up data. I suppose that's when someone can go read the upgrade notes. :)
Why not *always* use E'' if the server can handle it? I'd rather see
that consistently applied than only when there's a backslash, so people
aren't scratching their heads about the occasional odd E'' quote (which
many assume is a mistake until they learn about it). It'd be simpler as
well.
I considered this route, and the consistency is a very strong argument.
The one counter-argument is that using E only when needed is the way
Postgres itself does it, via the internal quote_literal function. Would
a large notice in the docs for quote() be enough to dispel the potential
head scratching if we made it E-as-needed? The other counter-argument is
that E'' is pretty ugly and noisy if not needed, and it won't be 99% of
the time. I'm still on the fence, but leaning towards "as needed".
Ok, if Postgres's quote_literal does it that way, it makes sense to follow
suit.
Thanks,
Jon
--
Jon Jensen
End Point Corporation
http://www.endpoint.com/
