Subject Re: [Firebird-Architect] DDL, Scripts, DFW, and Commit
Author Arno Brinkman

> DFW and metadata operations subject to transaction control are artifacts
> of supporting direct update of system tables. There were a number of
> reasons that I wanted to support direct update of system tables in
> Rdb/ELN and Interbase, but based on reflection and experience, I'm
> willing to concede they were wrong.
> The original Interbase engine didn't not have support for DDL, nor was
> there a generally accepted DDL to support. This is not longer the case,
> however.
> The pre-Vulcan implementation of SQL DDL is layered rather than
> integral, which requires support for direction update of system tables.
> Vulcan, however, pushes "dsql" into the engine proper, and could
> dispense with direct update of system tables in entirety.
> I'd like people to think about the implications of dropping support for
> direct update of system tables in favor of internal engine support for
> proper SQL DDL. The implementation would certainly use an ad hoc
> special transation committed or rolled back on a per statement basis.
> The same semantics would probably makes sense to retrofit over DYN,
> which I wouldn't mind dropping, but probably isn't feasible to do so.
> Decommitting direct update of system tables wouldn't necessarily
> eliminate DFW immediately, but would turn it from a general mechaninsm
> into one restricted to support well defined, bounded, internal
> Thoughts?

If every possible action is put in a nice SQL DDL statement this should be
good, but i think many thirth party programs use the system tables for
actions that aren't possible at all with DDL. Changing a NOT NULL field to a
NULLable field for example.
I often set the default collation of a database which also isn't possible
with a DDL command.

Arno Brinkman

Firebird open source database (based on IB-OE) with many SQL-99 features :

Support list for Interbase and Firebird users :

Nederlandse firebird nieuwsgroep :