Listing triggers in partitions (was Re: Remove mention in docs thatforeign keys on partitioned tables)

Поиск
Список
Период
Сортировка
От Alvaro Herrera
Тема Listing triggers in partitions (was Re: Remove mention in docs thatforeign keys on partitioned tables)
Дата
Msg-id 20180627210113.kjch2c3klieum6mu@alvherre.pgsql
обсуждение исходный текст
Ответ на Re: Remove mention in docs that foreign keys on partitioned tablesare not supported  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Ответы Re: Listing triggers in partitions (was Re: Remove mention in docsthat foreign keys on partitioned tables)  (David Rowley <david.rowley@2ndquadrant.com>)
Re: Listing triggers in partitions (was Re: Remove mention in docsthat foreign keys on partitioned tables)  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
Список pgsql-hackers
Gmail users: this comes from https://postgr.es/m/20180627191819.6g73wu7ck23fdhv6@alvherre.pgsql

On 2018-Jun-27, Alvaro Herrera wrote:

> On 2018-Jun-19, Amit Langote wrote:
> 
> > In CreateTrigger(), 86f575948c7 did this.
> > 
> > -    values[Anum_pg_trigger_tgisinternal - 1] = BoolGetDatum(isInternal);
> > +    values[Anum_pg_trigger_tgisinternal - 1] = BoolGetDatum(isInternal ||
> > in_partition);
> > 
> > I'm not sure why it had to be done, but undoing this change doesn't seem
> > to break any regression tests (neither those added by 86f575948c7 nor of
> > the partitioned table foreign key commit).  Did we really intend to change
> > the meaning of tginternal like this here?
> 
> I'm pretty sure pg_dump breaks if you turn that flag off for triggers in
> partitions, because pg_dump is going to emit commands to create those
> triggers, and those fail.

After idlying some more on this, I think one possibility is to add
another column to pg_trigger to differentiate triggers that should not
be shown by psql nor dumped, from triggers that should be shown by psql
but not dumped.

Two possibilities:
a) a boolean flag, "trgpartition" or something like that, indicating
that this is a trigger in a partition.  pg_dump does not dump such
triggers, but psql shows them.

b) an OID, pointing to the parent trigger.  This could theoretically
help a future implementation of BEFORE ROW triggers, as discussed
before (if trigger trgparent has already run for this row, don't run the
current trigger).  However, it's easy to revamp pg_trigger definition in
pg12 to add this column and remove the boolean one, so unless there is
some other immediate use for trgparent then there's no point.

Another angle is that we're already in beta3 and there may be concerns
about altering catalog definition this late in the cycle.  Anybody?
Maybe psql can just match tgisinternal triggers by name, and if one
match occurs then we assume it's a clone that should be listed as a
partition trigger.

-- 
Álvaro Herrera                https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: ALTER TABLE on system catalogs
Следующее
От: Adrien Nayrat
Дата:
Сообщение: Re: New GUC to sample log queries