>
> >4) I concur that SQL extensions are better than DBI; have you considered
> >a DBIx subclass implementation, ala DBIx::Chart ?
> >
> I'm not sure what the benefit of that would be over keeping it in
> SQL::Statement, please clue me in if I'm missing something.
Sorry, got my layers inverted...SQL::Statement would be the app's interface,
rather than DBI, per se, yes ?
(BTW & OT: <general question> whatever became of Inline::SQL ?)
>
> >5) Distributed INSERT ... SELECT, UPDATE..FROM, or DELETE ... WHERE x IN
> >(SELECT...)
> >supported ? (possible transactional issues, I suppose...)
> >
> The only subqueries I'm contemplating so far are CREATE INTO x FROM y
> ... and SELECT INTO x FROM y, basically a way to dump from one rdbms to
> another rather than the kind of fine tuning you are talking about, but
> maybe in the future.
Ditto to Mssr. Bunce's comments...I believe the ANSI is "CREATE TABLE ... AS
(SELECT....)
[ WITH [ NO ] DATA ]".
Are there specific issues with INSERT...SELECT and UPDATE FROM syntax that
concern you ? I may be able to dig up my (admittedly hacked) implementation
but the basic ANSI-type syntax isn't too complicated, is it ?
"INSERT INTO [EMAIL PROTECTED](optional columnlist)
SELECT <expression list> FROM [EMAIL PROTECTED]
WHERE ...."
would presumably morph into
$orasth = $oradbh->prepare("INSERT INTO mytable VALUES(<some number of
PHs>)");
$db2sth = $db2dbh->prepare("SELECT <expression list> FROM sometable
WHERE....");
$dbhsth->execute;
$orasth->execute_array($db2sth, { ArrayTupleStatus => [EMAIL PROTECTED] });
(Sorry if I'm trespassing...just hoping to be helpful...)
>
> >6) Any minimum i/f requirements from the underlying DBD's ?
> >
>
> I don't think so, it will just essentially create a $dbh using the DBD
> and keep that stored in a lookup table.
>
> --
> Jeff
>
Dean Arnold
Presicient Corp.
