Re: [HACKERS] Indicate disabled triggers in \d
Patch applied by Neil. Thanks. --- Brendan Jurd wrote: > On 11/7/06, Brendan Jurd <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Indicate disabled triggers in \d
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 <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Indicate disabled triggers in \d
On 11/7/06, Brendan Jurd <[EMAIL PROTECTED]> 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. describe.c.diff Description: Binary data ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] Indicate disabled triggers in \d
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 describe.c.diff Description: Binary data ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Indicate disabled triggers in \d
On Mon, Nov 06, 2006 at 09:12:32AM -0500, Andrew Dunstan wrote: > Tom Lane wrote: > >"Brendan Jurd" <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> http://fetter.org/ phone: +1 415 235 3778AIM: dfetter666 Skype: davidfetter Remember to vote! ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] Indicate disabled triggers in \d
Tom Lane wrote: "Brendan Jurd" <[EMAIL PROTECTED]> 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 ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Indicate disabled triggers in \d
"Brendan Jurd" <[EMAIL PROTECTED]> 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() regards, tom lane ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
