Re: [ dspam-Bug Tracker-3023888 ] Wrong escaping of bytea (signature data) with postgresql 8.4
Stevan Bajić <[email protected]>
| Newsgroups | gmane.mail.spam.dspam.devel |
|---|---|
| Message-ID | <[email protected]> |
On Mon, 23 Aug 2010 08:06:49 +0200 Alban Hertroys <[email protected]> wrote: [...] > This is almost certainly due to the user having changed the PostgreSQL setting 'standard_conforming_strings' to 'on'. > But he was claiming that he got that error from a stock PostgreSQL installation. Could it be that there are distros setting this entry to 'on'? > Admittedly that would be the preferable way to interpret strings, but it's not the default (compatibility reasons mostly). > > dspam=> SHOW standard_conforming_strings ; > standard_conforming_strings > ----------------------------- > off > (1 row) > I got the same result on my PostgreSQL 9b2 test installation: template1=# SHOW standard_conforming_strings; standard_conforming_strings ----------------------------- off (1 row) template1=# [...] > That's not true either. The E'' syntax is to denote non-standard-conforming strings, meaning they don't conform to the SQL standard and contain backslash escapes (like \' instead of ''). > Yes. My wording was wrong but I meant exactly what you have written. > I don't think signature data is in fact meaningful text, is it? > No. It's not text. It is indeed binary. > If I understand correctly it's actually a binary string, > Correct. > in which case bytea would indeed be the more appropriate data-format to use. > It is already 'bytea'. I mean the table has already 'bytea' for the 'data' column. > And Stevan is correct that you don't need any stored procedures for that. Bytea is supported in versions <= 7.4 too, for those who still use that. > The only difference we have for older releases of PostgreSQL is that we use the API PQescapeBytea and for the newer PostgreSQL releases we use PQescapeByteaConn to escape the data when writing it to dspam_signature_data. When reading the data we use the API PQunescapeBytea to unescape the data back to a binary format. I really don't know why that should not work with stock PostgreSQL 8.4? > Alban Hertroys > -- Kind Regards from Switzerland, Stevan Bajić ------------------------------------------------------------------------------ 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