On Nov 14, Neil wrote:
>>I'd like to implement FOR EACH STATEMENT triggers. AFAICS it shouldn't>>be too tricky -- so if there's some
show-stopperthat prevented it>>from being done earlier, let me know now, please :-)
>>Some random notes on the implementation I'm thinking of:
>> - in the function called by a per-statement trigger, no>> references to the 'OLD' or 'NEW' rows will be allowed
It appears that statement triggers are implemented this way right now in
CVS tip. Unfortunately, this means that there's no way to figure out the
record set that is covered by the triggering action, which I consider
being fundamental for a usable implementation. There should be new
references,
called OLDSET and NEWSET or something like that.
>> - should we allow per-statement BEFORE triggers? DB2 doesn't,>> but I'm not sure that's because they just cut
corners,or if>> there's some legitimate reason not to allow them. AFAICT SQL>> 200x doesn't specify that they *aren't*
allowed,so I'm>> inclined to allow them...
MS SQL2000 has only AFTER STATEMENT triggers too, which seems to be
sufficient.
I had a look at the trigger calling code in execMain.c. For BEFORE ROW
triggers, a compare of rows before and after trigger execution is
performed, row by row. Figuring out the difference could be difficult
for statement triggers, so it might be reasonable to disallow BEFORE
STATEMENT triggers. Additional effect is that the OLDSET and NEWSET
record sets visible to the trigger code only need to be read-only, which
solves the problem deciding whether an update to NEWSET will itself fire
triggers or not.
Is there any more work on statement triggers planned or going on right now?
Regards,
Andreas
