Re: SQL Extensions for SQL::Statement [Long]

[Jeff Zucker]

Dean Arnold wrote:

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

You and me both :)  And this whole mess I am introducing will fuzz the 
layers even more I'm afraid.

...SQL::Statement would be the app's interface,
rather than DBI, per se, yes ?
Umm, no, SQL::Statement is the RDBMS.  DBD::CSV, DBD::AnyData, 
DBD::Excel etc use it as the underlying engine to parse and evaluate the 
SQL.  So all of the changes I am suggesting will be available in the 
DBDs that use SQL::Statement (though depending on how things work out 
some of them may be specific to DBD::AnyData).   You can access 
SQL::Statement directly without those DBDs though I'm thinking that just 
using DBD::AnyData as a front end to it may be easier in some cases.

One consequence of all this is, one will be able to use, for example 
DBD::AnyData to join two XBase tables even though DBD::XBase (the last I 
looked) doesn't support joins:

       SELECT *
         FROM [EMAIL PROTECTED]
    LEFT JOIN [EMAIL PROTECTED]
(BTW & OT: <general question> whatever became of Inline::SQL ?)

Never heard of it, sorry.

"INSERT INTO [EMAIL PROTECTED](optional columnlist)
SELECT <expression list> FROM [EMAIL PROTECTED]
WHERE ...."
would presumably morph into

$orasth = $oradbh->prepare("INSERT ...

Yep.

(Sorry if I'm trespassing...just hoping to be helpful...)

Quite the contrary, I *much* appreciate your comments and questions, 
keep 'em coming.

Hopefully I'll have this all sorted out enough to explain it in plain 
English at the OSCON BOF.

--
Jeff