Tim Bunce wrote:
> >
> > Teradata supports named placeholders. The syntax is
> > :NAME, ie, SELECT * FROM TABLE WHERE COL1 = :col1;
>
> So it matches Oracle syntax. Does DBD::Teradata allow
> $sth->bind_param(":col1", $foo);
> like DBD::Oracle? If not, could it?
No, it currently doesn't, but Yes, it (fairly easily) could.
I've been considering it for some time, but (like so many
things) time/resources didn't permit.
>
> > BTW: I don't see anything in DBI 1.38 that checks for
> > numeric parameter ID in bind_param() (tho bind_param_array() does),
> > so is it safe to assume individual drivers *could* just implement such
> > (non-portable) support on their own
>
> Yes. DBD::Oracle always has.
>
> > (excluding array-binding support, and the "default"
> > binding via execute()/execute_array()). Which also raises the issue of how
> > the default bindings would map to named PHs (perhaps a simple arrayref
> > of the names supplied as an attribute ?)
>
> No. The only thing I'd be happy with is what DBD::Oracle does.
> Use implicit placeholder names for the value so
>
> $sth->execute($foo, $bar);
>
> is the same as
>
> $sth->bind_param(":p1", $foo)
> $sth->bind_param(":p2", $bar)
> $sth->execute();
>
Explicit binding in this case is OK by me...is there any collision here with
the on-going row-wise vs. column-wise array binding thread ?
> Interestingly, the way it does that is to translate 'normal'
> placeholders into :p1, :p2 etc when the SQL is prepared.
> Then bind_param(1, ...) is treated as bind_param(":p1",...)
> which then means the Driver.xst for execute() "just works".
>
> Tim.
Which is effectively what DBD::Teradata does, ie, the 1st named PH
occurance becomes PH 1, the 2nd becomes 2, etc. Actually, DBD::Teradata
currently doesn't pay much attention to what the app binds in that case, as there's
an explicit USING clause required to declare the order/type of the named
PHs. Formal support of named PHs would permit the DBD to generate the
USING clause internally if it was missing.
Jim Cromie wrote:
>
> Does this preclude the following ? (as I proposed in 1st message of thread)
>
> $sth->execute( { ":p1" => $foo, ":p2" => $bar } );
>
> such an argument looks to be non-interfering with current usage,
> and would be an error w.o named placeholders in the statement's SQL.
> Multiple hashrefs could supply values for all the bindings, with later ones
> supplying defaults not previously given.
>
>
Alas, since execute() currently doesn't support an attribute hash,
might it break some existing drivers ? I can certainly sympathize with
the desire for brevity, but I fear the existing function i/f isn't readily backward
compatible with your particular usage (at least in a portable manner)...
interestingly, execute_array() could be made compatible, since it does have an
attribute hash.
Dean Arnold
Presicient Corp.
www.presicient.com
