Hi All,
I would like to implement the 'DISABLE TRIGGER' functionality for
Postgres...
My proposal for a syntax are the following..... We could choose either or
all of the following....
a) ALTER TABLE <table_name> DISABLE|ENABLE ALL TRIGGERS
(This syntax is available in oracle to alter all triggers for any given
table. We could make the 'ALL' optional...)
b) ALTER TABLE <table_name> DISABLE|ENABLE TRIGGER <trigger_name>
c) ALTER TRIGGER <trigger_name> DISABLE|ENABLE
(This syntax is available in oracle to alter individual triggers)
Another important issue is how to handle deferred triggers..... Considering
a scenario where the status of a trigger is changed when it is already in a
deferred stack,
a) We can update the corresponding entry of that particular trigger, which
is in the deferred stack, in the system table and when it comes up for
execution we can check its status. Depending upon the status of the
'tgenabled' it will either be executed or ignored.
b) Oracle has a different approach, When it encounters a DDL statement like
'ALTER TRIGGER' it will execute the deferred DML statements before that and
will then run the DDL statement... So for the above scenario, the trigger
will be run with whatever status it came into the deferred stack.
And finally about the scope of the change of status of a trigger. Should this
be local to the session or should be reflected globally? My humble opinion is
it should be reflected globally(again, as in oracle ?)....
Rgds,
Arul
This is an email from Fujitsu Australia Software Technology Pty Ltd, ABN 27 003 693 481. It is confidential to the
ordinaryuser of the email address to which it was addressed and may contain copyright and/or legally privileged
information.No one else may read, print, store, copy or forward all or any of it or its attachments. If you receive
thisemail in error, please return to sender. Thank you.
If you do not wish to receive commercial email messages from Fujitsu Australia Software Technology Pty Ltd, please
emailunsubscribe@fast.fujitsu.com.au