Re: invalidating cached plans

Tom Lane wrote:
> I would like to see this folded together with creation of a centralized
> plan caching module.

Interesting. Can you elaborate on how you'd envision call sites making
use of this module?

> The difficulty with this after-the-fact approach is that the finished
> plan tree may contain no reference to some objects that it in fact
> depends on. SQL functions that have been inlined are the classic
> example, but consider also the idea that a plan may have been made on
> the strength of a table constraint (see nearby thread about partitioning)
> and needs to be invalidated if that constraint goes away.

Hmm, good point. I'm happy to blow away all cached plans when a table
constraint changes, so that resolves that, but I agree we'll need to
handle inlined functions specially. But perhaps it is best to not rely
on after-the-fact Plan analysis at all, and build the capability to
record plan dependencies directly into the planner.

-Neil