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/
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.