I am working on the opposite end of things, Selecting array types and other
OCI objects (vararry, tables etc) which is a different kettle of fish (no
doubt you will have some comments on how it has to be kludged in DBD::Oracle
to work with OCI but we will save that for another thread.) .
I support the way Alexander originally had it set up as it a little cleaner
and more consistent at least when I was working with it.
Just my 2cents worth
Cheers
John Scoles
----- Original Message -----
From: "Tim Bunce" <[EMAIL PROTECTED]>
To: "Alexander V Alekseev" <[EMAIL PROTECTED]>
Cc: "Tim Bunce" <[EMAIL PROTECTED]>; <[email protected]>
Sent: Tuesday, September 11, 2007 7:30 AM
Subject: Re: [patch] (final) DBD::Oracle - Support for standard array binds.
On Tue, Sep 11, 2007 at 02:15:27AM +0400, Alexander V Alekseev wrote:
On Mon, 10 Sep 2007, Tim Bunce wrote:
>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.
Hey, don't give in so easily! You can still persuade me. I'm teetering
on the end.
Anyone else have any opinions?
Do any other databases support array types? Can they be NULL?
Tim.
