Обсуждение: Indicate disabled triggers in \d
Hello hackers, I noticed that the table description given by \d <tablename> in psql does not indicate whether a trigger is enabled or disabled. In my opinion, if a trigger is disabled, that fact is essential information that a person looking at the output of \d would want to know. I would like to add this feature (and am happy to provide a patch), and I'd like your input on how it should be displayed. My first impulse was to just append a " (disabled)" after each disabled trigger, but perhaps that is not visually obvious enough, especially if the table has many triggers on it. Triggers: y AFTER DELETE ON x FOR EACH ROW EXECUTE PROCEDURE do_something() z BEFORE INSERT ON x FOR EACH ROW EXECUTEPROCEDURE input_stuff() (disabled) You could make it more clear by putting the disabled notice on a separate line with another level of indentation, but could look very messy with lots of triggers on the table: Triggers: y AFTER DELETE ON x FOR EACH ROW EXECUTE PROCEDURE do_something() z BEFORE INSERT ON x FOR EACH ROW EXECUTEPROCEDURE input_stuff() - disabled At the moment my preference is for disabled triggers to be shown as a separate footer section, like so: Triggers: y AFTER DELETE ON x FOR EACH ROW EXECUTE PROCEDURE do_something() Disabled triggers: z BEFORE INSERT ON x FOR EACH ROW EXECUTE PROCEDURE input_stuff() I think this provides the best clarity, and has the added bonus of leaving the trigger definition intact. Thanks for your time, BJ
"Brendan Jurd" <direvus@gmail.com> writes: > My first impulse was to just append a " (disabled)" after each > disabled trigger, but perhaps that is not visually obvious enough, > especially if the table has many triggers on it. Agreed, but maybe put it up at the front? Triggers: y AFTER DELETE ON x FOR EACH ROW EXECUTE PROCEDURE do_something() z (disabled) BEFORE INSERT ON x FOR EACHROW EXECUTE PROCEDURE input_stuff() regards, tom lane
Tom Lane wrote: > "Brendan Jurd" <direvus@gmail.com> writes: > >> My first impulse was to just append a " (disabled)" after each >> disabled trigger, but perhaps that is not visually obvious enough, >> especially if the table has many triggers on it. >> > > Agreed, but maybe put it up at the front? > > Triggers: > y AFTER DELETE ON x FOR EACH ROW EXECUTE PROCEDURE do_something() > z (disabled) BEFORE INSERT ON x FOR EACH ROW EXECUTE PROCEDURE input_stuff() > > > +1. This bit me recently. Or maybe, in the interests of preserving screen space, a [*] for enabled and [x] for disabled, or something similar. cheers andrew
On Mon, Nov 06, 2006 at 09:12:32AM -0500, Andrew Dunstan wrote: > Tom Lane wrote: > >"Brendan Jurd" <direvus@gmail.com> writes: > > > >>My first impulse was to just append a " (disabled)" after each > >>disabled trigger, but perhaps that is not visually obvious enough, > >>especially if the table has many triggers on it. > >> > > > >Agreed, but maybe put it up at the front? > > > >Triggers: > > y AFTER DELETE ON x FOR EACH ROW EXECUTE PROCEDURE do_something() > > z (disabled) BEFORE INSERT ON x FOR EACH ROW EXECUTE PROCEDURE > > input_stuff() > > +1. This bit me recently. Or maybe, in the interests of preserving > screen space, a [*] for enabled and [x] for disabled, or something > similar. For this case, I think clarity is more important than saving screen space. Cheers, D -- David Fetter <david@fetter.org> http://fetter.org/ phone: +1 415 235 3778 AIM: dfetter666 Skype: davidfetter Remember to vote!
As discussed briefly on pgsql-hackers, the current psql \d command does not make any distinction between enabled and disabled triggers. The attached patch modifies psql's describeOneTableDetails() such that triggers and disabled triggers are displayed as two separate footer lists, for example: Triggers: y AFTER DELETE ON x FOR EACH ROW EXECUTE PROCEDURE do_something() Disabled triggers: z BEFORE INSERT ON x FOR EACH ROW EXECUTE PROCEDURE input_stuff() The patch compiled and tested cleanly on my machine, and passed all regression tests. I didn't find any relevant documentation that needed patching, so this feature add should work fine as a standalone patch. Regards, BJ
Вложения
On 11/7/06, Brendan Jurd <direvus@gmail.com> wrote: > As discussed briefly on pgsql-hackers, the current psql \d command > does not make any distinction between enabled and disabled triggers. > > The attached patch modifies psql's describeOneTableDetails() such that > triggers and disabled triggers are displayed as two separate footer > lists, for example: > Minor fix to the previous patch; result7 was not being cleared at the end of the block.
Вложения
On Tue, 2006-11-07 at 16:21 +1100, Brendan Jurd wrote: > Minor fix to the previous patch; result7 was not being cleared at the > end of the block. The patch still leaks result7 circa line 1400 (CVS HEAD). I didn't look closely, but you probably also leak result7 circa line 1209, if result6 is NULL. (Yeah, we definitely need to refactor describeOneTableDetails().) -Neil
On 11/11/06, Neil Conway <neilc@samurai.com> wrote: > > The patch still leaks result7 circa line 1400 (CVS HEAD). I didn't look > closely, but you probably also leak result7 circa line 1209, if result6 > is NULL. New version of the patch attached (against CVS HEAD) that fixes these two issues. > (Yeah, we definitely need to refactor describeOneTableDetails().) I'd be interested in doing some work on this. What did you have in mind? BJ
Вложения
This has been saved for the 8.3 release: http://momjian.postgresql.org/cgi-bin/pgpatches_hold --------------------------------------------------------------------------- Brendan Jurd wrote: > On 11/7/06, Brendan Jurd <direvus@gmail.com> wrote: > > As discussed briefly on pgsql-hackers, the current psql \d command > > does not make any distinction between enabled and disabled triggers. > > > > The attached patch modifies psql's describeOneTableDetails() such that > > triggers and disabled triggers are displayed as two separate footer > > lists, for example: > > > > Minor fix to the previous patch; result7 was not being cleared at the > end of the block. [ Attachment, skipping... ] > > ---------------------------(end of broadcast)--------------------------- > TIP 6: explain analyze is your friend -- Bruce Momjian bruce@momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
Patch applied by Neil. Thanks. --------------------------------------------------------------------------- Brendan Jurd wrote: > On 11/7/06, Brendan Jurd <direvus@gmail.com> wrote: > > As discussed briefly on pgsql-hackers, the current psql \d command > > does not make any distinction between enabled and disabled triggers. > > > > The attached patch modifies psql's describeOneTableDetails() such that > > triggers and disabled triggers are displayed as two separate footer > > lists, for example: > > > > Minor fix to the previous patch; result7 was not being cleared at the > end of the block. [ Attachment, skipping... ] > > ---------------------------(end of broadcast)--------------------------- > TIP 6: explain analyze is your friend -- Bruce Momjian bruce@momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +