Re: BUG #4417: Foreign keys do not work after altering table/column names

Tom Lane wrote:
> Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> writes:
>> Benjamin Bihler wrote:
>>> Unfortunately it is not possible to give more details, since these scripts
>>> are part of a commercial product.
>
>> It's unlikely that anyone can help you without more details.
>
> Although the OP could certainly have worked a bit harder at providing a
> self-contained example, it's not hard to reproduce a problem:
>
> ...

Oh, good.

> My first thought was some kind of callback function to construct the
> query text afresh, but that seems pretty baroque. It'd be simpler
> to just have an option to let plancache.c return a failure indication
> when its plan is obsolete, whereupon ri_triggers.c discards that plan
> and builds a fresh one. [ pokes around... ] Hm, the fly in that
> ointment is that ri_triggers and plancache aren't communicating directly
> but through SPI. I'm really loath to change the SPI API for this;
> is there another way?

ri_triggers.c could register a callback to invalidate entries in its
hash table with CacheRegisterRelcacheCallback() ?

Adding a new function, say SPI_is_plan_valid(plan), doesn't seem too bad
to me either.

--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com