Subject | Re: [IB-Architect] SQL Statement Depandance Mapping |
---|---|
Author | Charlie Caro |
Post date | 2000-06-30T17:01:54Z |
Jim Starkey wrote:
called DYN (dynamic DDL) for DDL statements. DYN is yet another
byte encoded language for describing data definition statements.
Jim created the DYN language when our VARs were demanding a way
to upgrade their customers databases in the field. The customers'
databases were licensed for run-time operation only. The high-level
tool, GDEF, which performed DDL operations was unlicensed. So, Jim
created a low-level, byte-encoded language which GDEF generated
from a high-level, GDEF script. The VARs could then distribute the
machine-generated DYN to their clients to modify the underlying
metadata. I guess you could call DYN an obfuscated, back door for
metadata operations.
Today, the same server-side DSQL parser generates parse trees for
both SQL DML and DDL statements. The DDL parse trees are passed
to a component which emits DYN. That DYN is immediately passed to
the Y-valve entrypoint ISC_DDL which interprets the DYN and performs
the actions on the system tables.
So the behavior is as Jim describes but the path is a bit more
circuitous than one would expect.
Regards,
Charlie
>The DSQL component emits BLR for DML statements and something
> DDL is a different story. The real DDL operations are performed
> by ordinary DML to the system tables. SQL DDL is what is known
> in the biz as syntactic sugar.
>
called DYN (dynamic DDL) for DDL statements. DYN is yet another
byte encoded language for describing data definition statements.
Jim created the DYN language when our VARs were demanding a way
to upgrade their customers databases in the field. The customers'
databases were licensed for run-time operation only. The high-level
tool, GDEF, which performed DDL operations was unlicensed. So, Jim
created a low-level, byte-encoded language which GDEF generated
from a high-level, GDEF script. The VARs could then distribute the
machine-generated DYN to their clients to modify the underlying
metadata. I guess you could call DYN an obfuscated, back door for
metadata operations.
Today, the same server-side DSQL parser generates parse trees for
both SQL DML and DDL statements. The DDL parse trees are passed
to a component which emits DYN. That DYN is immediately passed to
the Y-valve entrypoint ISC_DDL which interprets the DYN and performs
the actions on the system tables.
So the behavior is as Jim describes but the path is a bit more
circuitous than one would expect.
Regards,
Charlie