From: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> |
---|---|
To: | Hari Krishna Sunder <hari(dot)db(dot)pg(at)gmail(dot)com> |
Cc: | Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Should TRUNCATE fire DDL triggers |
Date: | 2025-07-09 21:18:45 |
Message-ID: | CAKFQuwYZV1CCbrvvMObiab+nX2fu3K6rF8Rax9pUea13tUitcg@mail.gmail.com |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wednesday, July 9, 2025, Hari Krishna Sunder <hari(dot)db(dot)pg(at)gmail(dot)com>
wrote:
> > I disagree here. There are regular ON TRUNCATE triggers on tables, so I
> don't
> > see the need. You can define a trigger with the same trigger function on
> > several tables.
>
> You have to create a trigger for each table, and drop them before you drop
> the table. The DDL trigger will just work more seamlessly.
> If we say this is not a DDL, then how about supporting a wildcard as the
> table_name in the BEFORE/ALTER TRUNCATE trigger?
>
We avoid top-posting replies here.
I’d probably go with adding truncate_start and truncate_end (or maybe just
start…) events for event triggers if we don’t want to include them under
DDL events. I’d be strongly disinclined to touch regular triggers to
accommodate whatever use case you have that would benefit from this
capability. Stating what that is helps to get agreement, or just spending
time helping, making such changes.
David J.
From | Date | Subject | |
---|---|---|---|
Next Message | Christoph Berg | 2025-07-09 21:21:59 | Re: CHECKPOINT unlogged data |
Previous Message | Damien Clochard | 2025-07-09 21:14:46 | [PATCH] Generate random dates/times in a specified range |