[REVIEW] psql tab completion for DROP TRIGGER/RULE and ALTER TABLE ... DISABLE/ENABLE

From: Ian Barwick <ian(at)2ndquadrant(dot)com>
To: Andreas Karlsson <andreas(at)proxel(dot)se>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: [REVIEW] psql tab completion for DROP TRIGGER/RULE and ALTER TABLE ... DISABLE/ENABLE
Date: 2014-06-17 11:36:16
Message-ID: 53A02830.1080500@2ndquadrant.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Andreas Karlsson (andreas(at)proxel(dot)se) wrote:
> Hi,
>
> When benchmarking an application I got annoyed at how basic the tab
> completion for ALTER TABLE ... DISABLE/ENABLE TRIGGER and DROP TRIGGER
> is. So here is a patch improving the tab completion around triggers. For
> consistency I have also added the same completions to rules since their
> DDL is almost identical.

Thanks for this patch; I'm playing around with rules at the moment and it was
very useful. A quick review:

- applies cleanly to HEAD

- does what it claims, i.e. adds tab completion support for this syntax:

ALTER TABLE table { ENABLE | DISABLE } [ ALWAYS | REPLICA ] { RULE | TRIGGER } rule_or_trigger
DROP TRIGGER trigger ON relation { CASCADE | RESTRICT }
DROP RULE rule ON relation { CASCADE | RESTRICT }

- code style is consistent with the project style

One issue - the table's internal triggers will also be listed. which can result in
something like this:

database=> ALTER TABLE object_version DISABLE TRIGGER <TAB>
"RI_ConstraintTrigger_a_1916401" "RI_ConstraintTrigger_a_1916422" "RI_ConstraintTrigger_c_1916358"
"RI_ConstraintTrigger_a_1916402" "RI_ConstraintTrigger_c_1916238" "RI_ConstraintTrigger_c_1916359"
"RI_ConstraintTrigger_a_1916406" "RI_ConstraintTrigger_c_1916239" "RI_ConstraintTrigger_c_1916398"
"RI_ConstraintTrigger_a_1916407" "RI_ConstraintTrigger_c_1916263" "RI_ConstraintTrigger_c_1916399"
"RI_ConstraintTrigger_a_1916411" "RI_ConstraintTrigger_c_1916264" "RI_ConstraintTrigger_c_1916478"
"RI_ConstraintTrigger_a_1916412" "RI_ConstraintTrigger_c_1916298" "RI_ConstraintTrigger_c_1916479"
"RI_ConstraintTrigger_a_1916416" "RI_ConstraintTrigger_c_1916299" "RI_ConstraintTrigger_c_1916513"
"RI_ConstraintTrigger_a_1916417" "RI_ConstraintTrigger_c_1916328" "RI_ConstraintTrigger_c_1916514"
"RI_ConstraintTrigger_a_1916421" "RI_ConstraintTrigger_c_1916329" ts_vector_update

This is a bit of an extreme case, but I don't think manually manipulating
internal triggers (which can only be done as a superuser) is a common enough
operation to justify their inclusion. I suggest adding
'AND tgisinternal is FALSE' to 'Query_for_trigger_of_table' to hide them.

Regards

Ian Barwick

--
Ian Barwick http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Abhijit Menon-Sen 2014-06-17 11:47:13 [REVIEW] Re: Compression of full-page-writes
Previous Message Pavel Stehule 2014-06-17 10:49:28 Re: wrapping in extended mode doesn't work well with default pager