Re: [HACKERS] psql should show disabled internal triggers
On Wed, Feb 12, 2014 at 09:04:45PM -0500, Bruce Momjian wrote: As others, I am concerned about people being confused when funny-looking trigger names suddenly appearing when you disable all table triggers. What I ended up doing is to create a user and internal section when displaying disabled triggers: Disabled user triggers: check_update BEFORE UPDATE ON orders FOR EACH ROW EXECUTE PROCEDURE trigf() Disabled internal triggers: RI_ConstraintTrigger_c_16409 AFTER INSERT ON orders FROM customer NOT DEF ... RI_ConstraintTrigger_c_16410 AFTER UPDATE ON orders FROM customer NOT DEF ... I kept the Triggers section unchanged, showing only user triggers. I also updated the code to handle 8.3+ servers. Patch attached. Patch applied. -- Bruce Momjian br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.com + Everyone has their own god. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] psql should show disabled internal triggers
On 2014-02-24 12:45:12 -0500, Bruce Momjian wrote: On Wed, Feb 12, 2014 at 09:04:45PM -0500, Bruce Momjian wrote: As others, I am concerned about people being confused when funny-looking trigger names suddenly appearing when you disable all table triggers. What I ended up doing is to create a user and internal section when displaying disabled triggers: Disabled user triggers: check_update BEFORE UPDATE ON orders FOR EACH ROW EXECUTE PROCEDURE trigf() Disabled internal triggers: RI_ConstraintTrigger_c_16409 AFTER INSERT ON orders FROM customer NOT DEF ... RI_ConstraintTrigger_c_16410 AFTER UPDATE ON orders FROM customer NOT DEF ... I kept the Triggers section unchanged, showing only user triggers. I also updated the code to handle 8.3+ servers. Patch attached. Patch applied. Thanks. It'd have been nice tho, to mention Fabrízio in the commit message as the patch's author. Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] psql should show disabled internal triggers
On Mon, Feb 24, 2014 at 07:09:29PM +0100, Andres Freund wrote: On 2014-02-24 12:45:12 -0500, Bruce Momjian wrote: On Wed, Feb 12, 2014 at 09:04:45PM -0500, Bruce Momjian wrote: As others, I am concerned about people being confused when funny-looking trigger names suddenly appearing when you disable all table triggers. What I ended up doing is to create a user and internal section when displaying disabled triggers: Disabled user triggers: check_update BEFORE UPDATE ON orders FOR EACH ROW EXECUTE PROCEDURE trigf() Disabled internal triggers: RI_ConstraintTrigger_c_16409 AFTER INSERT ON orders FROM customer NOT DEF ... RI_ConstraintTrigger_c_16410 AFTER UPDATE ON orders FROM customer NOT DEF ... I kept the Triggers section unchanged, showing only user triggers. I also updated the code to handle 8.3+ servers. Patch attached. Patch applied. Thanks. It'd have been nice tho, to mention Fabrízio in the commit message as the patch's author. Uh, I was thinking of that, but I basically rewrote the patch from scratch and changed its visible behavior, so I was worried about perhaps blaming him if it introduced a bug. I should have said original patch by ..., but because so much of it was new, I didn't bother. -- Bruce Momjian br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.com + Everyone has their own god. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] psql should show disabled internal triggers
On 2014-02-24 13:16:39 -0500, Bruce Momjian wrote: On Mon, Feb 24, 2014 at 07:09:29PM +0100, Andres Freund wrote: On 2014-02-24 12:45:12 -0500, Bruce Momjian wrote: On Wed, Feb 12, 2014 at 09:04:45PM -0500, Bruce Momjian wrote: As others, I am concerned about people being confused when funny-looking trigger names suddenly appearing when you disable all table triggers. What I ended up doing is to create a user and internal section when displaying disabled triggers: Disabled user triggers: check_update BEFORE UPDATE ON orders FOR EACH ROW EXECUTE PROCEDURE trigf() Disabled internal triggers: RI_ConstraintTrigger_c_16409 AFTER INSERT ON orders FROM customer NOT DEF ... RI_ConstraintTrigger_c_16410 AFTER UPDATE ON orders FROM customer NOT DEF ... I kept the Triggers section unchanged, showing only user triggers. I also updated the code to handle 8.3+ servers. Patch attached. Patch applied. Thanks. It'd have been nice tho, to mention Fabrízio in the commit message as the patch's author. Uh, I was thinking of that, but I basically rewrote the patch from scratch and changed its visible behavior, so I was worried about perhaps blaming him if it introduced a bug. I should have said original patch by ..., but because so much of it was new, I didn't bother. I just seems nicer to relatively new contributors to mention their names when they try to contribute. Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] psql should show disabled internal triggers
On Mon, Feb 24, 2014 at 3:23 PM, Andres Freund and...@2ndquadrant.com wrote: Thanks. It'd have been nice tho, to mention Fabrízio in the commit message as the patch's author. Uh, I was thinking of that, but I basically rewrote the patch from scratch and changed its visible behavior, so I was worried about perhaps blaming him if it introduced a bug. I should have said original patch by ..., but because so much of it was new, I didn't bother. I just seems nicer to relatively new contributors to mention their names when they try to contribute. Hey guys, I'm not worried about it... to me the most important thing is the improvement and the learning. So I'm happy to help in some way. Regards, -- Fabrízio de Royes Mello Consultoria/Coaching PostgreSQL Timbira: http://www.timbira.com.br Blog sobre TI: http://fabriziomello.blogspot.com Perfil Linkedin: http://br.linkedin.com/in/fabriziomello Twitter: http://twitter.com/fabriziomello
Re: [HACKERS] psql should show disabled internal triggers
On Mon, Feb 24, 2014 at 07:23:50PM +0100, Andres Freund wrote: On 2014-02-24 13:16:39 -0500, Bruce Momjian wrote: On Mon, Feb 24, 2014 at 07:09:29PM +0100, Andres Freund wrote: On 2014-02-24 12:45:12 -0500, Bruce Momjian wrote: On Wed, Feb 12, 2014 at 09:04:45PM -0500, Bruce Momjian wrote: As others, I am concerned about people being confused when funny-looking trigger names suddenly appearing when you disable all table triggers. What I ended up doing is to create a user and internal section when displaying disabled triggers: Disabled user triggers: check_update BEFORE UPDATE ON orders FOR EACH ROW EXECUTE PROCEDURE trigf() Disabled internal triggers: RI_ConstraintTrigger_c_16409 AFTER INSERT ON orders FROM customer NOT DEF ... RI_ConstraintTrigger_c_16410 AFTER UPDATE ON orders FROM customer NOT DEF ... I kept the Triggers section unchanged, showing only user triggers. I also updated the code to handle 8.3+ servers. Patch attached. Patch applied. Thanks. It'd have been nice tho, to mention Fabrízio in the commit message as the patch's author. Uh, I was thinking of that, but I basically rewrote the patch from scratch and changed its visible behavior, so I was worried about perhaps blaming him if it introduced a bug. I should have said original patch by ..., but because so much of it was new, I didn't bother. I just seems nicer to relatively new contributors to mention their names when they try to contribute. Agreed. -- Bruce Momjian br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.com + Everyone has their own god. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] psql should show disabled internal triggers
On Thu, Nov 21, 2013 at 11:59:51PM -0200, Fabrízio de Royes Mello wrote:
On Fri, Oct 25, 2013 at 3:37 PM, fabriziomello fabriziome...@gmail.com
wrote:
On 2013-09-18 15:15:55 +0200, Bernd Helmle wrote:
On 2013-09-18 15:15:55 +0200, Bernd Helmle wrote:
--On 18. September 2013 13:52:29 +0200 Andres Freund
lt;andres@gt; wrote:
If you do ALTER TABLE ... DISABLE TRIGGER ALL; and then individually
re-enable the disabled triggers it's easy to miss internal triggers.
A \d+ tablename will not show anything out of the ordinary for that
situation since we don't show internal triggers. But foreign key checks
won't work.
So, how about displaying disabled internal triggers in psql?
Hi had exactly the same concerns this morning while starting to look at
the
ENABLE/DISABLE constraint patch. However, i wouldn't display them as
triggers, but maybe more generally as disabled constraints or such.
Well, that will lead the user in the wrong direction, won't it? They
haven't disabled the constraint but the trigger. Especially as we
already have NOT VALID and might grow DISABLED for constraint
themselves...
Hi,
The attached patch [1] enable PSQL to list internal disabled triggers in \d
only in versions = 9.0.
[1] psql-display-all-triggers-v1.patch
http://postgresql.1045698.n5.nabble.com/file/n5775954/
psql-display-all-triggers-v1.patch
As others, I am concerned about people being confused when funny-looking
trigger names suddenly appearing when you disable all table triggers.
What I ended up doing is to create a user and internal section when
displaying disabled triggers:
Disabled user triggers:
check_update BEFORE UPDATE ON orders FOR EACH ROW EXECUTE PROCEDURE
trigf()
Disabled internal triggers:
RI_ConstraintTrigger_c_16409 AFTER INSERT ON orders FROM customer
NOT DEF ...
RI_ConstraintTrigger_c_16410 AFTER UPDATE ON orders FROM customer
NOT DEF ...
I kept the Triggers section unchanged, showing only user triggers. I
also updated the code to handle 8.3+ servers.
Patch attached.
--
Bruce Momjian br...@momjian.ushttp://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has their own god. +
diff --git a/src/bin/psql/describe.c b/src/bin/psql/describe.c
new file mode 100644
index 3cb8df2..a194ce7
*** a/src/bin/psql/describe.c
--- b/src/bin/psql/describe.c
*** describeOneTableDetails(const char *sche
*** 2090,2104
printfPQExpBuffer(buf,
SELECT t.tgname,
pg_catalog.pg_get_triggerdef(t.oid%s),
! t.tgenabled\n
FROM pg_catalog.pg_trigger t\n
WHERE t.tgrelid = '%s' AND ,
(pset.sversion = 9 ? , true : ),
! oid);
if (pset.sversion = 9)
! appendPQExpBufferStr(buf, NOT t.tgisinternal);
else if (pset.sversion = 80300)
! appendPQExpBufferStr(buf, t.tgconstraint = 0);
else
appendPQExpBufferStr(buf,
(NOT tgisconstraint
--- 2090,2108
printfPQExpBuffer(buf,
SELECT t.tgname,
pg_catalog.pg_get_triggerdef(t.oid%s),
! t.tgenabled, %s\n
FROM pg_catalog.pg_trigger t\n
WHERE t.tgrelid = '%s' AND ,
(pset.sversion = 9 ? , true : ),
! (pset.sversion = 9 ? t.tgisinternal :
! pset.sversion = 80300 ?
! t.tgconstraint 0 AS tgisinternal :
! false AS tgisinternal), oid);
if (pset.sversion = 9)
! /* display/warn about disabled internal triggers */
! appendPQExpBuffer(buf, (NOT t.tgisinternal OR (t.tgisinternal AND t.tgenabled = 'D')));
else if (pset.sversion = 80300)
! appendPQExpBufferStr(buf, (t.tgconstraint = 0 OR (t.tgconstraint 0 AND t.tgenabled = 'D')));
else
appendPQExpBufferStr(buf,
(NOT tgisconstraint
*** describeOneTableDetails(const char *sche
*** 2124,2130
* disabled triggers and the two special ALWAYS and REPLICA
* configurations.
*/
! for (category = 0; category 4; category++)
{
have_heading = false;
for (i = 0; i tuples; i++)
--- 2128,2134
* disabled triggers and the two special ALWAYS and REPLICA
* configurations.
*/
! for (category = 0; category = 4; category++)
{
have_heading = false;
for (i = 0; i tuples; i++)
*** describeOneTableDetails(const char *sche
*** 2133,2143
--- 2137,2149
const char *tgdef;
const char *usingpos;
const char *tgenabled;
+ const char *tgisinternal;
/*
* Check if this trigger falls into the current category
*/
tgenabled = PQgetvalue(result, i, 2);
+ tgisinternal = PQgetvalue(result, i, 3);
list_trigger = false;
switch (category)
{
*** describeOneTableDetails(const char *sche
*** 2146,2159
Re: [HACKERS] psql should show disabled internal triggers
On Thu, Feb 13, 2014 at 12:04 AM, Bruce Momjian br...@momjian.us wrote: On Thu, Nov 21, 2013 at 11:59:51PM -0200, Fabrízio de Royes Mello wrote: On Fri, Oct 25, 2013 at 3:37 PM, fabriziomello fabriziome...@gmail.com wrote: On 2013-09-18 15:15:55 +0200, Bernd Helmle wrote: On 2013-09-18 15:15:55 +0200, Bernd Helmle wrote: --On 18. September 2013 13:52:29 +0200 Andres Freund lt;andres@gt; wrote: If you do ALTER TABLE ... DISABLE TRIGGER ALL; and then individually re-enable the disabled triggers it's easy to miss internal triggers. A \d+ tablename will not show anything out of the ordinary for that situation since we don't show internal triggers. But foreign key checks won't work. So, how about displaying disabled internal triggers in psql? Hi had exactly the same concerns this morning while starting to look at the ENABLE/DISABLE constraint patch. However, i wouldn't display them as triggers, but maybe more generally as disabled constraints or such. Well, that will lead the user in the wrong direction, won't it? They haven't disabled the constraint but the trigger. Especially as we already have NOT VALID and might grow DISABLED for constraint themselves... Hi, The attached patch [1] enable PSQL to list internal disabled triggers in \d only in versions = 9.0. [1] psql-display-all-triggers-v1.patch http://postgresql.1045698.n5.nabble.com/file/n5775954/ psql-display-all-triggers-v1.patch As others, I am concerned about people being confused when funny-looking trigger names suddenly appearing when you disable all table triggers. What I ended up doing is to create a user and internal section when displaying disabled triggers: Disabled user triggers: check_update BEFORE UPDATE ON orders FOR EACH ROW EXECUTE PROCEDURE trigf() Disabled internal triggers: RI_ConstraintTrigger_c_16409 AFTER INSERT ON orders FROM customer NOT DEF ... RI_ConstraintTrigger_c_16410 AFTER UPDATE ON orders FROM customer NOT DEF ... I kept the Triggers section unchanged, showing only user triggers. I also updated the code to handle 8.3+ servers. Patch attached. Makes more sense than my previous patch... The code looks fine to me!! Regards, -- Fabrízio de Royes Mello Consultoria/Coaching PostgreSQL Timbira: http://www.timbira.com.br Blog sobre TI: http://fabriziomello.blogspot.com Perfil Linkedin: http://br.linkedin.com/in/fabriziomello Twitter: http://twitter.com/fabriziomello
Re: [HACKERS] psql should show disabled internal triggers
On Fri, Oct 25, 2013 at 3:37 PM, fabriziomello fabriziome...@gmail.com wrote: On 2013-09-18 15:15:55 +0200, Bernd Helmle wrote: On 2013-09-18 15:15:55 +0200, Bernd Helmle wrote: --On 18. September 2013 13:52:29 +0200 Andres Freund lt;andres@gt; wrote: If you do ALTER TABLE ... DISABLE TRIGGER ALL; and then individually re-enable the disabled triggers it's easy to miss internal triggers. A \d+ tablename will not show anything out of the ordinary for that situation since we don't show internal triggers. But foreign key checks won't work. So, how about displaying disabled internal triggers in psql? Hi had exactly the same concerns this morning while starting to look at the ENABLE/DISABLE constraint patch. However, i wouldn't display them as triggers, but maybe more generally as disabled constraints or such. Well, that will lead the user in the wrong direction, won't it? They haven't disabled the constraint but the trigger. Especially as we already have NOT VALID and might grow DISABLED for constraint themselves... Hi, The attached patch [1] enable PSQL to list internal disabled triggers in \d only in versions = 9.0. [1] psql-display-all-triggers-v1.patch http://postgresql.1045698.n5.nabble.com/file/n5775954/psql-display-all-triggers-v1.patch Hi all, I'm just send a new WIP patch rebased from master. Regards, -- Fabrízio de Royes Mello Consultoria/Coaching PostgreSQL Timbira: http://www.timbira.com.br Blog sobre TI: http://fabriziomello.blogspot.com Perfil Linkedin: http://br.linkedin.com/in/fabriziomello Twitter: http://twitter.com/fabriziomello diff --git a/src/bin/psql/describe.c b/src/bin/psql/describe.c index 96322ca..f457e21 100644 --- a/src/bin/psql/describe.c +++ b/src/bin/psql/describe.c @@ -2079,7 +2079,7 @@ describeOneTableDetails(const char *schemaname, (pset.sversion = 9 ? , true : ), oid); if (pset.sversion = 9) - appendPQExpBufferStr(buf, NOT t.tgisinternal); + appendPQExpBuffer(buf, (NOT t.tgisinternal OR (t.tgisinternal AND t.tgenabled = 'D'))); else if (pset.sversion = 80300) appendPQExpBufferStr(buf, t.tgconstraint = 0); else -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] psql should show disabled internal triggers
On 2013-09-18 15:15:55 +0200, Bernd Helmle wrote: On 2013-09-18 15:15:55 +0200, Bernd Helmle wrote: --On 18. September 2013 13:52:29 +0200 Andres Freund lt;andres@gt; wrote: If you do ALTER TABLE ... DISABLE TRIGGER ALL; and then individually re-enable the disabled triggers it's easy to miss internal triggers. A \d+ tablename will not show anything out of the ordinary for that situation since we don't show internal triggers. But foreign key checks won't work. So, how about displaying disabled internal triggers in psql? Hi had exactly the same concerns this morning while starting to look at the ENABLE/DISABLE constraint patch. However, i wouldn't display them as triggers, but maybe more generally as disabled constraints or such. Well, that will lead the user in the wrong direction, won't it? They haven't disabled the constraint but the trigger. Especially as we already have NOT VALID and might grow DISABLED for constraint themselves... Hi, The attached patch [1] enable PSQL to list internal disabled triggers in \d only in versions = 9.0. [1] psql-display-all-triggers-v1.patch http://postgresql.1045698.n5.nabble.com/file/n5775954/psql-display-all-triggers-v1.patch Regards, -- Fabrízio de Royes Mello Consultoria/Coaching PostgreSQL Timbira: http://www.timbira.com.br Blog sobre TI: http://fabriziomello.blogspot.com Perfil Linkedin: http://br.linkedin.com/in/fabriziomello Twitter: http://twitter.com/fabriziomello - -- Fabrízio de Royes Mello Consultoria/Coaching PostgreSQL Blog sobre TI: http://fabriziomello.blogspot.com Perfil Linkedin: http://br.linkedin.com/in/fabriziomello Twitter: http://twitter.com/fabriziomello -- View this message in context: http://postgresql.1045698.n5.nabble.com/psql-should-show-disabled-internal-triggers-tp5771406p5775954.html Sent from the PostgreSQL - hackers mailing list archive at Nabble.com. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] psql should show disabled internal triggers
Andres Freund and...@2ndquadrant.com writes: So, how about displaying disabled internal triggers in psql? +1 -- Dimitri Fontaine http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] psql should show disabled internal triggers
--On 18. September 2013 13:52:29 +0200 Andres Freund and...@2ndquadrant.com wrote: If you do ALTER TABLE ... DISABLE TRIGGER ALL; and then individually re-enable the disabled triggers it's easy to miss internal triggers. A \d+ tablename will not show anything out of the ordinary for that situation since we don't show internal triggers. But foreign key checks won't work. So, how about displaying disabled internal triggers in psql? Hi had exactly the same concerns this morning while starting to look at the ENABLE/DISABLE constraint patch. However, i wouldn't display them as triggers, but maybe more generally as disabled constraints or such. -- Thanks Bernd -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] psql should show disabled internal triggers
On 2013-09-18 15:15:55 +0200, Bernd Helmle wrote: --On 18. September 2013 13:52:29 +0200 Andres Freund and...@2ndquadrant.com wrote: If you do ALTER TABLE ... DISABLE TRIGGER ALL; and then individually re-enable the disabled triggers it's easy to miss internal triggers. A \d+ tablename will not show anything out of the ordinary for that situation since we don't show internal triggers. But foreign key checks won't work. So, how about displaying disabled internal triggers in psql? Hi had exactly the same concerns this morning while starting to look at the ENABLE/DISABLE constraint patch. However, i wouldn't display them as triggers, but maybe more generally as disabled constraints or such. Well, that will lead the user in the wrong direction, won't it? They haven't disabled the constraint but the trigger. Especially as we already have NOT VALID and might grow DISABLED for constraint themselves... Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] psql should show disabled internal triggers
--On 18. September 2013 15:19:27 +0200 Andres Freund and...@2ndquadrant.com wrote: Well, that will lead the user in the wrong direction, won't it? They haven't disabled the constraint but the trigger. Especially as we already have NOT VALID and might grow DISABLED for constraint themselves... Valid point. But it is also nice to know in detail, which constraints stopped working. Ok, it is documented which constraints are affected and maybe i'm lost within too much detail atm, but i find people getting confused about this internal trigger thingie sometimes. Won't they get confused about a suddenly appearing RI_ConstraintTrigger_a_54015, too? -- Thanks Bernd -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
