Subject | RE: [IB-Architect] A few more suggestions |
---|---|
Author | Jim Starkey |
Post date | 2000-06-05T16:08:55Z |
At 08:58 AM 6/5/00 -0700, David Schnepper wrote:
support for DDL operations. The obvious solution would be to add
a BLR verb to interprete an arbitrary character string.
Superficially, it seems simple. In practice, it is a potential
can of worms. For example, a DDL request could delete and/or
recreate a table that has already been resolved during compilation
and preparation of the stored procedure -- very much like pulling
the rug out from underneath your feet. Figuring out what is legal
and what is not and finding ways to catch everything that is not
is probably doable, but by no means simple.
Dynamic SQL is also doable, but the interaction of DSQL and the
internal engine context has some interesting design problems
involving interaction of compiled and dynamic stuff. Again,
doable.
Combining DSQL and dynamic DDL into the same mechanism is almost
certainly the right answer, but a solution has the union of the
problems list above.
Good master thesis material.
Jim Starkey
>re: Dynamic SQL from within an SP.The essential problem is that BLR (last time I looked) doesn't have
>
>I don't think that is asking for a "bit much" -- Oracle supports this. My
>head has been churning the last
>few weeks about how this could be added within IB.
>
>Along the lines of "defining the problem" -- Louis, can you define some DDL
>operations that
>you've wanted to do in a SP, but haven't been able to?
>
support for DDL operations. The obvious solution would be to add
a BLR verb to interprete an arbitrary character string.
Superficially, it seems simple. In practice, it is a potential
can of worms. For example, a DDL request could delete and/or
recreate a table that has already been resolved during compilation
and preparation of the stored procedure -- very much like pulling
the rug out from underneath your feet. Figuring out what is legal
and what is not and finding ways to catch everything that is not
is probably doable, but by no means simple.
Dynamic SQL is also doable, but the interaction of DSQL and the
internal engine context has some interesting design problems
involving interaction of compiled and dynamic stuff. Again,
doable.
Combining DSQL and dynamic DDL into the same mechanism is almost
certainly the right answer, but a solution has the union of the
problems list above.
Good master thesis material.
Jim Starkey