Re: [HACKERS] Bug in prepared statement cache invalidation? - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [HACKERS] Bug in prepared statement cache invalidation?
Date
Msg-id 13536.1493761842@sss.pgh.pa.us
Whole thread Raw
In response to Re: [HACKERS] Bug in prepared statement cache invalidation?  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: [HACKERS] Bug in prepared statement cache invalidation?  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
Robert Haas <robertmhaas@gmail.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



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: [HACKERS] Bug in prepared statement cache invalidation?
Next
From: Alvaro Herrera
Date:
Subject: Re: [HACKERS] changing mvstats output to be valid JSON