mark warren bracher wrote:
Peter J. Holzer wrote:
On 2007-09-03 13:03:37 +0100, Tim Bunce wrote:
Oh the joys of Oracle character set support.
See the dbd_rebind_ph() code in dbdimp.c. Especially from the line
"csform = phs->csform;" onwards.
You can explicitly set the csform and csid using bind_param(..., {
... })
[snip]
stumbled on this thread while debugging a problem with full table scans
binding utf8 strings into oracle queries...
it seems the degraded performance is "expected"
http://download-uk.oracle.com/docs/cd/B10501_01/server.920/a96529/ch6.htm#1008756
when you used csform SQLCS_NCHAR and the database column is CHAR,
VARCHAR2 or CLOB. same is true of the reverse, using SQLCS_IMPLICIT
when the column is NCHAR, NVARCHAR2, NCLOB.
perhaps we need to rework CSFORM_IMPLIES_UTF8 so it doesn't return true
for csform SQLCS_NCHAR if the columns are CHAR, VARCHAR2 or CLOB?
As I think about this some more, I realize that this sort of
introspection into the table structure may not be possible at the point
we're binding values. Merely reversing the preference won't work, as
SQLCS_IMPLICIT when using N* types is equally troublesome or worse.
Beyond performance concerns, the grid in the OCI docs mention data loss
for that case...
Perhaps it would work to have a ora_default_csform_behavior (or similar)
that could be set on the dbh and checked in dbd_rebind_ph(), so that
users of CHAR, VARCHAR2 and CLOB would not need to bind every utf8 value
explicitly. That strikes me as a bit clunky, but not as clunky as
recoding every bind_param() call to pass an explicit ora_csform value...
- mark
