Re: [ dspam-Bug Tracker-3023888 ] Wrong escaping of bytea (signature data) with postgresql 8.4

W dniu 23.08.2010 11:28, Stevan Bajić pisze:
> Most data is just INT, BIGINT or DATE.
> 
> In three tables we use VARCHAR:
> - In 'dspam_signature_data' for 'signature'
> - In 'dspam_preferences' for 'preference' and 'value'
> - In 'dspam_virtual_uids' for 'username'
> 
> In one table we use BYTEA:
> - In 'dspam_signature_data' for 'data'
> 
> So the only place where we need to escape/unescape is the places where we use VARCHAR and BYTEA.
> 
> We could avoid escaping the VARCHAR for the table dspam_signature_data since that 'signature' will probably never have a character in it that would need escaping. In the 'dspam_preferences' table the 'preference' will too not have a character that needs escaping. But 'value' from 'dspam_preferences' could have characters that would need escaping/unescaping and the 'username' from 'dspam_virtual_uids' could have characters that need escaping/unescaping. The 'data' from 'dspam_signature_data' will probably always need to use E'' notation.
> 
> So IMHO the PostgreSQL driver should not fiddle around with 'standard_conforming_strings' and either enforce everywhere the E'' notation (would slow down the driver because of escaping/unescaping) or just use escaping/unescaping where we anyway can't go without (dspam_signature_data.data, dspam_virtual_uids.username and dspam_preferences.value).
> 
> What do you think about this approach?

Value of "standard_conforming_strings" is going to change in default
configuration. In 8.4 it's off, in 9.1 will be on. This value doesn't
exist in postgresql earlier than 8.2.
Quote from postgresql doc, section PQescapeBytea:
"The only difference from PQescapeByteaConn is that PQescapeBytea does
not take a PGconn  parameter. Because of this, it cannot adjust its
behavior depending on the connection properties (in particular, whether
standard-conforming strings are enabled) ..."
Imvho, should we worry about standard_conforming_strings? Function
PQescapeByteaConn should do escaping in right way. If we don't want
pgdriver to use E'' (performance) dspam should check if pgsql>=8.2 then
"set standard_conforming_strings=on" and PQescapeByteaConn should
properly encode data.
The same about varchar: PQescapeStringConn should take parameters of
connection and do correct escaping.
It's theory :)

Btw, problem could be if dspam would connect to pgsql<7.4 , but should
dspam worry about dinosaur?
Regards,
Marcin

-- 
xmpp (jabber): marcin  [at]  mejor.pl
www: http://blog.mejor.pl/

------------------------------------------------------------------------------
This SF.net email is sponsored by 

Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev 
_______________________________________________
Dspam-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/dspam-devel