Vlad Khorsun escreveu:

>> <ddl event> ::=
>> ANY DDL EVENT
>> | <ddl event list>
>>
>> <ddl event list> ::=
>> <ddl event item>
>> | <ddl event list> OR <ddl event item>
>> * There will be a limit on number of items on this list. If I'm not
>> wrong, it can have a max of 13 items.
>>
>
> Why this limitation ?
>

To store it on RDB$TRIGGER_TYPE.

>
>
>> <ddl event item> ::=
>> CREATE TABLE
>>
> ...
>
>
>> DDL_TRIGGER context namespace
>>
>
> Not sure i like context's more than old good 'OLD' and 'NEW' pseudo tables.
>
>
>> - DDL_EVENT: event name (<ddl event item>)
>>
>
> We already have UPDATED and DELETED system functions for table's triggers.
> I prefer to be consistent with it. For example we may introduce new system functions
> such as CREATED\ALTERED\DROPPED or even use existing UPDATED (for ALTER)
> and DELETED (for DROP) functions. And, of course, introduce new function OBJECT_TYPE.
>
>
>> - OBJECT_NAME: metadata object name
>>
>
> Its ok and may be used with OLD and NEW
>
>
>> - SQL_TEXT: sql statement text
>>
>
> This one we can use with NEW only. Note, when CREATEing and ALTERing procedures
> and triggers our parser cut off statement header. I think it is not good and like to change it
> in FB3. But i worry about backward compatibility... DDL Triggers adds one more argument
> to store full text of procedures and triggers.
>

I like static typing/syntax, but OLD and NEW seems not correct for DDL
triggers. There is nothing different on them (i.e., OLD.SQL_TEXT doesn't
apply for objects different than triggers and procedures) and we don't
have object rename except for fields. We'll can also never update NEW in
DDL trigger.

>> The only practical difference from them should be that AFTER triggers
>> see updated metadata.
>>
>
> In system tables only. And we must explicitly warn user about it.
>

That they can't, for example, use a table in AFTER CREATE TABLE?
Certainly...


Adriano