On Mon, Sep 10, 2007 at 02:27:31PM +0400, Alexander V Alekseev wrote:
> >> Forgot to attach DBI patch, though I already sent it to the
> >>list. Patch is attached just to keep everything needed in a single list
> >>thread.
> >
> >And, for the same reason, I'll restate that the DBI patch is neither
> >needed nor appropriate. bind_param_inout() takes a reference to the
> >value. In this case that value is also a reference. All is well.
>
> 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.]
> 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?
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.)
Tim.
