Hello!
On Mon, 10 Sep 2007, Tim Bunce wrote:
From my example:
$sth->bind_param_inout(":mytable", [EMAIL PROTECTED], 10, {
TYPE => DBD::Oracle::ORA_VARCHAR2,
ora_maxarray_numentries => 100 } );
[TYPE is for specifying ISO-CLI/ODBC standard TYPE values, i.e. those
SQL_* constants like SQL_VARCHAR, SQL_INTEGER etc. So either use
TYPE => SQL_VARCHAR, or ora_type => TYPE => DBD::Oracle::ORA_VARCHAR2.]
You're right. It must be "ora_type => DBD::Oracle::ORA_VARCHAR2".
Here, "[EMAIL PROTECTED]" is a reference, but standard DBI declines it
as a reference to array. It accepts only reference to scalar.
Without change, user would have to:
my @arr1;
my [EMAIL PROTECTED];
my $ref2=\$ref1;
$sth->bind_param_inout(":mytable", $ref2 , 10 , ... )
There's no need for all that. You could just do this:
$sth->bind_param_inout(":mytable", [EMAIL PROTECTED] , 10 , ... )
Don't you think, it's better to use the first format ?
It's not really a question of one backslash vs two. It's more a question
of the principle behind the design of the API. Consistency trumps beauty
in the long run.
Annoyingly for me I can argue it both ways in this case.
Here's a question for you: what happens when the returnd value is NULL?
How can you distinguish that from an empty array?
Hmmm... In this particular case, Oracle object "TABLE OF ...
INDEX BY BINARY INTEGER" can't be NULL. As far, as I know, it's
impossible in Oracle.
With the current API you could do this:
$sth->bind_param_inout(":mytable", \my $ary = [EMAIL PROTECTED] , 10 ,
... )
die "got null" if !$ary;
(I'll admit I've made that rather terse, but that's not the point here.)
Ok. I'll change docs in my patch.
Bye. Alex.
