At 11:09 AM 7/31/2004 -0400, Tom Lane wrote:
>All the supported encodings are supersets of ASCII, so I don't think
>there is any such risk.
Is the 7.4.x multibyte support bombproof? How would we avoid problems like
this:
http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&c2coff=1&safe=off&edition=us&selm=20020502171830J.t-ishii%40sra.co.jp
Summary of that problem: an invalid multibyte character "eats" the
following character.
I know it's fixed already, but is there a way to reduce exposure to such bugs?
>There is a risk in the opposite direction I think: if the escaping
>function doesn't know the encoding being used
>it might think that one byte of a multibyte character is ' or \ and try to
>escape it, thereby breaking the data.
Is the escaping function always consistent with the backend's
interpretation? Is it impossible for them to be inconsistent (e.g. they use
the same code to interpret data).
My concern is if the escaping function thinks one byte of a multibyte is \
but the rest of the backend doesn't then you can end up with an escaped
backslash which does not escape a naughty '...
Also: what is the proper/official way to deal with:
update tablea set data=3-? where a=1;
And the parameter is -1
Somehow ensure it's always like this?
update tablea set data=3 - ? where a=1;
This doesn't seem to be escaped safely for: DBD::Pg 1.22 (3 versions old)
with Postgresql 7.3.4
Would it be best to do the 3-? part in the application and then do update
tablea set data=? where a=1;
Possibly result in less CPU usage at backend too.
Regards,
Link.