Re: [HACKERS] Bug in prepared statement cache invalidation?

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: [HACKERS] Bug in prepared statement cache invalidation?
Дата
Msg-id 13536.1493761842@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: [HACKERS] Bug in prepared statement cache invalidation?  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: [HACKERS] Bug in prepared statement cache invalidation?  (Robert Haas <robertmhaas@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: [HACKERS] Bug in prepared statement cache invalidation?
Следующее
От: Alvaro Herrera
Дата:
Сообщение: Re: [HACKERS] changing mvstats output to be valid JSON