Tim Bunce wrote, on 15/08/2005 14:36:
On Mon, Aug 15, 2005 at 12:07:03PM +0100, Charles Jardine wrote:
Peter J. Holzer wrote, on 14/08/2005 09:23:
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.
Sorry. I did insufficient research before forming a plan.
I was intending to provide silent upgrading for byte-encoded
statements being prepared when the client side database
charset is utf8.
Now Tim points out that this is not how bound input values
behave in the current implementation, I realise I have to think
again.
So, I won't be submitting a patch soon. When I can find time,
I will post with the intention of starting a discussion
about upgrading and downgrading.
--
Charles Jardine - Computing Service, University of Cambridge
[EMAIL PROTECTED] Tel: +44 1223 334506, Fax: +44 1223 334679
