Tim Bunce wrote, on 17/08/2005 21:23:
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:

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.)

I am aware that there are worms. This is why I need more time to
think before say anything.

If the $statement is UTF8 then simply tell Oracle that it's UTF8.
Simple.

Unfortunately this isn't as easy as it is when binding. OCI
statement handles do not support OCI_ATTR_CHARSET_ID. They
inherit their encoding settings from their environment handle
at create time, and do not expose them for inspection or
change. It seems it will be necessary to create the statement
handle using a different environment handle. As a side effect,
this will change the default charsets for bind and define
handles under this statement handle. This, in turn, may
require change in the code for binding and defining to
preserve the existing behaviour.

This patch is going to take some time. Nevertheless, I
shall attempt it. It would be good to have the behaviour of
prepare() consistent with that of bind_param().

--
Charles Jardine - Computing Service, University of Cambridge
[EMAIL PROTECTED]    Tel: +44 1223 334506, Fax: +44 1223 334679

Reply via email to