On 1/30/18 04:49, Amit Langote wrote:
>> If you are writing a generic
>> trigger function, maybe to dump out all columns, you want to know the
>> physical table and its actual columns. It's easy[citation needed] to
>> get the partition root for a given table, if the trigger code needs
>> that. The other way around is not possible.
>
> I guess you mean the root where a trigger originated, that is, ancestor
> table on which an inherited trigger was originally defined. It is
> possible for a trigger to be defined on an intermediate parent and not the
> topmost root in a partition tree.
OK, so maybe not so "easy".
But this muddies the situation even further. You could be updating
table A, which causes an update in intermediate partition B, which
causes an update in leaf partition C, which fires a trigger that was
logically defined on B and has a local child on C. Under this proposal,
the trigger will see TG_RELNAME = C. You could make arguments that the
trigger should also somehow know about B (where the trigger was defined)
and A (what the user actually targeted in their statement). I'm not
sure how useful these would be. But if you want to cover everything,
you'll need three values.
I think the patch can go ahead as proposed, and the other things could
be future separate additions.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
