On Sun, 25 Jul 2004 18:40:15 -0700, Dean Arnold typed:
> Matthew O. Persico wrote:
>>
>> My 0.02USD is this implementation detail: you have to tell
>> Filter::Simple not to replace the embedded SQL but to comment it
>> out and add the filtered code or else debugging will be a royal
>> PITA.
>
> Yep. And presumably, sprinkle with #line pragmas so line numbers of
> reported errors make sense.
Yep, I forgot about that.
>> 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.
> ...is a bit more convenient/familiar to us aging SQL hackers.
> And maybe for SQL hackers who don't know the DBI yet
> (if there are any ;^)
> And think of it...by running perl interactively, it may even
> possible
> to use perl instead of sqlplus/isql/etc. (Not too sure if Filter
> would handle that, tho)
Depends on if you can run Filter against an eval STRING expression.
>
>> --
>> Matthew O. Persico
>>
> Thanks,
> Dean
--
Matthew O. Persico
