Re: Prepared statements fail after schema changes with surprising error

* Tom Lane (tgl@sss.pgh.pa.us) wrote:
> Anyway, we're not talking about
> a back-patched fix I think, but something we'd change in a new major
> release.

Agreed.

> However, it could still come annoyingly
> close to "any DDL invalidates all cached plans", at least for apps that
> keep most of their objects in one schema.  Not entirely sure it's worth
> the implementation hassle and extra sinval traffic.

I'm really on the fence about this myself.  I can certainly see value in
doing the invalidations to provide an easy way for individuals to do
database updates which include DDL changes without downtime or even
having to pause all concurrent activity (consider a create-table, rename
old-table, rename-new-into-place, drop old-table approach).  That said,
that use-case may end up being vanishingly small due to the planned
queries themselves (or plpgsql functions) needing to be updated anyway.

Perhaps we can punt to the user on this in some way?  If a user needed
to invalidate these plans w/o having direct access to the client
connections involved (but having some appropriate access), could we
provide a mechanism for them to do so?  Might be a bit much as these
complaints don't seem to come up terribly often and restarting backends,
while annoying, isn't that bad if it isn't required very often.
Thanks,
    Stephen