On Mon, Aug 15, 2005 at 12:07:03PM +0100, Charles Jardine wrote:
> 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 ]
> >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.
Actually it's not quite what happens. There's no silent upgrading.
> >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.
Basically if the $statement scalar variable is marked as UTF8 then
tell OCI that the charset of the SQL statement is AL32UTF8.
If not then there should be *no change* to the current behaviour.
Tim.
