Peter J. Holzer wrote, on 14/08/2005 09:23:
On 2005-08-12 16:45:50 +0100, Charles Jardine wrote:
The method $dbh->prepare($stmt) of DBD::Oracle ignores the
state of the utf8 flag in the SV for $stmt.
[ snip ]
This is clearly a bug. It can affect any SQL statement which
contains a non-ASCII character. It can strike whether or not
Unicode is being used in the database. I would like to fix it.
This requires that code be put somewhere which decides how to
process the SV on the basis of its utf8 flag and of the
NLS_LANG charset.
I am not sure if it is possible to define the right behaviour.
Theoretically, it's simple. Since "\xe2" and decode_utf8("\xc3\xa2")
compare equal, they must be equal, so "\xe2" always is an "รข",
regardless of the NLS_LANG setting. DBD::Oracle would then convert all
strings to the client character set or quietly set the client character
set AL32UTF8 (or UTF8 for older Oracle versions).
However, I am sure there exist tons of code which expect that perl
strings are byte arrays in the client character set. This code would
then break.
I propose the following compromise:
If the client character set is AL32UTF8 or UTF8, then all strings passed
to prepare or inserted into or compared to varchar2 or clob fields are
silently upgraded to utf8. All varchar2 and clob values returned by
DBD::Oracle are in utf8 representation.
This what I am proposing for prepare. It already happens for values
sent of returned via placeholders and to fetched values.
Otherwise, all strings are treated as byte arrays in the client
character set.
The change I am proposing for 8-bit client character sets is that
the perl strings passed to prepare should be downgraded to bytes,
if necessary, before being treated as you say. This will not
affect any legacy perl code, but will fix a problem for code
like mine, which receives SQL over a utf8 channel and runs
it against a non-utf8 database.
--
Charles Jardine - Computing Service, University of Cambridge
[EMAIL PROTECTED] Tel: +44 1223 334506, Fax: +44 1223 334679
