Re: [HACKERS] delta relations in AFTER triggers

On Tue, Mar 14, 2017 at 7:51 AM, Kevin Grittner <kgrittn@gmail.com> wrote:
> On Sun, Mar 12, 2017 at 4:08 PM, Thomas Munro
> <thomas.munro@enterprisedb.com> wrote:
>> I found a new way to break it: run the trigger function so
>> that the plan is cached by plpgsql, then ALTER TABLE incompatibly,
>> then run the trigger function again.  See attached.
>
> [...]
>
> I expected that existing mechanisms would have forced re-planning of
> a trigger function if the table the function was attached to was
> altered.  Either that was a bit "optimistic", or the old TupleDesc
> is used for the new plan.  Will track down which it is, and fix it.

When PlanCacheRelCallback runs, I don't think it understands that
these named tuplestore RangeTblEntry objects are dependent on the
subject table.  Could that be fixed like this?

@@ -2571,6 +2582,9 @@ extract_query_dependencies_walker(Node *node,
PlannerInfo *context)                       if (rte->rtekind == RTE_RELATION)
context->glob->relationOids=
 

lappend_oid(context->glob->relationOids, rte->relid);
+                       else if (rte->rtekind == RTE_NAMEDTUPLESTORE)
+                               context->glob->relationOids =
+
lappend_oid(context->glob->relationOids, [subject table's OID]);               }

> I'll post a new patch once I figure out the dropped column on the
> cached function plan.

If that's fixed and the permissions question can be waved away by
saying it's the same as the per-row situation, my only other comment
would be a bikeshed issue: Enr isn't a great name for a struct.

Very keen to see this feature in PostgreSQL 10!

-- 
Thomas Munro
http://www.enterprisedb.com