Re: Prepared statements fail after schema changes with surprising error

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> I agree with that, but I think Tom's concern is more with the cost of
> too-frequent re-planning. The most obvious case in which DDL might be
> frequent enough to cause an issue here is if there is heavy use of
> temporary objects - sessions might be rapidly creating and dropping
> objects in their own schemas. It would be unfortunate if that forced
> continual replanning of queries in other sessions. I think there
> could be other cases where this is an issue as well, but the
> temp-object case is probably the one that's most likely to matter in
> practice.

Yeah, that is probably the major hazard IMO too. The designs sketched
in this thread would be sufficient to ensure that DDL in one session's
temp schema wouldn't have to invalidate plans in other sessions --- but
is that good enough?

Your point that the locking code doesn't quite cope with newly-masked
objects makes me feel that we could get away with not solving the case
for plan caching either. Or at least that we could put off the problem
till another day. If we are willing to just change plancache's handling
of search_path, that's a small patch that I think is easily doable for
9.3. If we insist on installing schema-level invalidation logic, it's
not happening before 9.4.

regards, tom lane