Обсуждение: 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. +