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