On 2018/01/31 9:44, Peter Eisentraut wrote:
> 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.
Yeah, I see no problem with going ahead with the patch as it for now.
Thanks,
Amit
