[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Macros Make Me Mad
It's not because of macros, but because it has a SQL sublanguage
integrated deeply into it. A misformed SQL query embedded into a
PL/SQL program will get a compile-time error, because it will be a
syntax error in the PL/SQL program, too. It's also fairly easy to mix
host language expressions with SQL queries, and it has a number of
syntactic constructs (select into, cursor for-loops) that make it less
needful to explicitly manage cursors.
You can *use* macros to build a sublanguage that gets you most of this
power in a general-purpose language. You can write your macro
definitions so that an improperly formed query will cause a host
language syntax error, and you can trivially add the iteration and
other constructs that make cursor management easier. The one big miss
with a macro sublanguage is that PL/SQL will check to make sure that
all of the columns and tables are all consistent before running, and
we can't do that, only because the compiler can't query the database.
I suppose a procedural macro system theoretically *could* do that(!),
but Needle's macros are based vaguely on an extensible grammar model.
Thanks Neel. I agree that the integration of SQL w/ the language
datatype *is* the big win (and loss) w/ PL/SQL. I thought you were
going to point out some creative way of using DBMS_SQL :). Personally
I've never cared too much for the syntax checking ability of PL/SQL
(wrt. column datatypes etc.) -- I know it's there, but given %type and
other such facilities, I rarely stumble across that type of error any
Personally speaking, if any of the LL languages could demonstrate such
deep integration w/ SQL (esp. wrt dynamic tables etc.) that could be
something genuinely new and worth looking into.