SEO

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 EXECUTE PROCEDURE 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 EXECUTE PROCEDURE 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

---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly

"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()

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

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


---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

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!

---------------------------(end of broadcast)---------------------------
TIP 7: You can help support the PostgreSQL project by donating at

http://www.postgresql.org/about/donate