Re: Bug in prepared statement cache invalidation?

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> Yeah. I think there should be a way to tell a PL to flush any
> internal caches it is maintaining, some variant of DISCARD. But that
> would require a bunch of code that nobody's written yet.

That mechanism already exists, so far as the core code is concerned:
register a syscache inval callback. But you're right, getting plpgsql
to actually do anything about changes in composite types would require
a bunch of code that nobody's written yet.

If you'll pardon my bashing on a long-deceased horse, this would be
noticeably easier if we stopped using the PLPGSQL_DTYPE_ROW code
paths for composite-type variables. That mechanism was really
designed for cases like "SELECT ... INTO a,b,c" where the row
contents are fully determined by the function text. It's practically
impossible to make it cope with dynamic changes; at the very least
you have to recompile the whole function.

regards, tom lane