Matthew O. Persico wrote:
To be honest, given a native API, I have never understood the
desire for embedded SQL. But TIMTOWTDI, so good luck.
Yes & no. Consider a quick little script to pull some data. Yes,
DBI is reasonably
compact, but maybe
use SQL::Preprocessor;
EXEC SQL CONNECT TO 'mydsn' USER userid IDENTIFIED BY password;
EXEC SQL SELECT * FROM mytable;
foreach my $row (@$_) {
print join(', ', @$row), "\n";
}
EXEC SQL DISCONNECT;
__END__
OOOOOH. The light goes on. I see. Yeah, that could be convenient. I wouldn't
necessarily want to do this many times in a large system, but for small self-contained
quickies, I grok.
Something to think about - one of the thing done quite often with DBI and the ilk is
to build queries on the fly. Someone is going to ask that question. Seems to me that
since this is all compile-time magic, run-time decisions aren't going to be possible.
Maybe you want to anticipate the question and squash such talk before it starts.
Actually, thats "dynamic SQL".
Assuming the "render on the fly" isn't *too* complicated, then
'EXEC SQL EXECUTE IMMEDIATE <string-expression>' will handle that.
Tho I might have to handle things like
EXEC SQL EXECUTE IMMEDIATE sub { some code returning a string } ;
Assuming no placeholders, that would return data (if any) in $_ ,
and dump PREPARE info into whatever was DECLARE SQLDA'd...tho I've
been thinking of implicitly defining a $SQLDA variable for the
latter case if no DECLARE SQLDA was given.
EXEC SQL PREPARE <stmt-name> FROM <string-expression >;
EXEC SQL EXECUTE <stmt-name> USING <variable-list>;
should cover placeholders.
But you've got me thinking it might be nice to define a SQL extension
to support connection pools for web apps (assuming existing DBI->connect()
functionality doesn't already handle that case).
Hmm, and maybe an implicit connect from some sort of initfile
or environment variable...or even a connection pool,
to trim that CONNECT stmt.
With an implicit connection, and DBI's implicit disconnect on exit,
that turns my simple example into:
use SQL::Preprocessor;
EXEC SQL SELECT * FROM mytable;
foreach my $row (@$_) {
print join(', ', @$row), "\n";
}
And even the foreach loop might be compacted
with some more implicit behaviors, e.g. an
EXEC SQL PRINT ...
statement.
Depends on if you can run Filter against an eval STRING expression.
Hmm, guess I'll have to study on that a spell...
--
Matthew O. Persico
- Dean
