Re: proposal: persistent plpgsql plugin info - field plugin_info for plpgsql_function structure

Поиск
Список
Период
Сортировка
От Alvaro Herrera
Тема Re: proposal: persistent plpgsql plugin info - field plugin_info for plpgsql_function structure
Дата
Msg-id 20131231184559.GX22570@eldon.alvh.no-ip.org
обсуждение исходный текст
Ответ на proposal: persistent plpgsql plugin info - field plugin_info for plpgsql_function structure  (Pavel Stehule <pavel.stehule@gmail.com>)
Ответы Re: proposal: persistent plpgsql plugin info - field plugin_info for plpgsql_function structure
Список pgsql-hackers
Pavel Stehule escribió:
> Hello
> 
> I am working on plpgsql_check and I would to write a protection against
> repeated check - so I need to mark a compiled (cached) function. Now,
> plpgsql extension can store own data to exec state, and I would to some
> similar for plpgsql_function. I believe so it can be useful for any plpgsql
> extension that collects data per signature (and recreating) means so
> refresh is necessary.

I'm not sure I understand this.  Do you want to avoid running the
checker if a previous run was seen as successful and function has not
changed?  Suppose the function depends on a table.  I invoke the check
(it succeeds), then drop the table, then invoke the check again.  What
should happen?  Conversely, if I invoke the check and it fails, then I
create the table and invoke the check again, what should happen?  How
does this idea of yours know when to invalidate the cached result of the
check when unrelated objects, which the function depends on, are
dropped/created/modified?

-- 
Álvaro Herrera                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Pavel Stehule
Дата:
Сообщение: proposal: persistent plpgsql plugin info - field plugin_info for plpgsql_function structure
Следующее
От: Mark Dilger
Дата:
Сообщение: Re: fix_PGSTAT_NUM_TABENTRIES_macro patch