On Wed, Aug 17, 2005 at 06:01:03PM +0100, Charles Jardine wrote: > 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.
Why? What I proposed requires less work and is in-keeping with how DBD::Oracle behaves for bind values etc. (If you want to change how DBD::Oracle behaves for bind values etc. then you're staring into a can of worms the size of which you can barely imagine. Trust me, I've been there along with a few brave souls who all bare the scars.) If the $statement is UTF8 then simply tell Oracle that it's UTF8. Simple. Tim.
