Re: Rename of triggers for partitioned tables

From: Arne Roland <A(dot)Roland(at)index(dot)de>
To: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
Cc: vignesh C <vignesh21(at)gmail(dot)com>, Zhihong Yu <zyu(at)yugabyte(dot)com>, Pg Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Rename of triggers for partitioned tables
Date: 2021-07-22 17:22:57
Message-ID: 29dca60bc79e4c2ab26fa328a94b1289@index.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


From: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
Sent: Thursday, July 22, 2021 18:20
To: Arne Roland
Subject: Re: Rename of triggers for partitioned tables

If we have good use for such an index, I don't see why we can't add it.
But I'm not sure that it is justified -- certainly if the only benefit
is to make ALTER TRIGGER RENAME recurse faster on partitioned tables, it
is not justified.

Speed is not really the issue here, most people will have under 20 triggers per table anyways. I think even the simpler code would be worth more than the speed gain. The main value of such an index would be the enforced uniqueness.

I just noticed that apparently the
ALTER TABLE [ IF EXISTS ] [ ONLY ] name [ ENABLE | DISABLE ] TRIGGER ...
syntax albeit looking totally different and it already recurses, it has precisely the same issue with pg_dump. In that case the ONLY syntax isn't optional and the 2. from your above post does inevitably apply.

Since it is sort of the same problem, I think it might be worthwhile to address it as well within this patch. Adding two to four ereports doesn't sound like scope creeping to me, even though it touches completely different code. I'll look into that as well.

Regards
Arne

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message John Naylor 2021-07-22 17:28:38 Re: truncating timestamps on arbitrary intervals
Previous Message tushar 2021-07-22 17:14:31 Re: refactoring basebackup.c