Re: Help needed with standard_conforming_strings
Jon Jensen <jon-O9fzpki4YnJWk0Htik3J/[email protected]>
| Newsgroups | gmane.comp.db.postgresql.dbdpg |
|---|---|
| Message-ID | <[email protected]> |
On Thu, 8 May 2008, Greg Sabino Mullane wrote: >> Couldn't DBD::Pg just switch to using ' to escape quotes? I mean, the >> problem is DBD::Pg escaping in $dbh->quote(), is it not? In that case, >> Just escape ' and not \ if SCS is on. > > 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. And are you familiar with cases where that has been done? I'm not. Strings are stored unquoted and quoted as needed; otherwise you end up with the always-cute PHP backslashes like \' and \\\' all over the place. > In reviewing this, I think I've overcomplicated matters. We don't need > to consider the status of standard_conforming_strings at all, we simply > need to always use E'' if 1) the string contain a backslash and 2) the > server can handle the E syntax. 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. Jon -- Jon Jensen End Point Corporation http://www.endpoint.com/