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 Dspam-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspam-devel
