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

Поиск
Список
Период
Сортировка
От Amit Kapila
Тема Re: proposal: persistent plpgsql plugin info - field plugin_info for plpgsql_function structure
Дата
Msg-id CAA4eK1+_uR3LTmiAjQ+_tfRt-iPMBXQDsAmJpW=5HRP5=VS8ZQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: proposal: persistent plpgsql plugin info - field plugin_info for plpgsql_function structure  (Pavel Stehule <pavel.stehule@gmail.com>)
Список pgsql-hackers
On Wed, Jan 1, 2014 at 12:52 AM, Pavel Stehule <pavel.stehule@gmail.com> wrote:
> 2013/12/31 Alvaro Herrera <alvherre@2ndquadrant.com>
>>
>> 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?
>
>
> plpgsql_check is designed for interactive (active) mode and passive mode. In
> interactive mode a enhanced checking is started by explicit request -
> explicit using plpgsql_check function - this feature is taken from patches
> that I sent to mailing list. In this mode a check is executed always (when
> checking is enabled) - and it is called repeatedly (when user requests it).
>
> Passive mode is taken from plpgsql_lint extension. It is plpgsql extension
> based on begin_func callback. plpgsql_lint doesn't support fatal_errors
> option - every detected error is fatal, that stops execution. plpgsql_check
> allows fatal_errors = false (plpgsql_check raises warnings only], and I am
> searching way how to minimize repeated warning messages. It is one
> motivation. Second motivation is increasing speed of regression tests by
> removing repeated check. Good idea is a function that removes mark from
> compiled function - so anybody can do recheck without leaving of session.

Will it really help by adding different modes for plpgsql_check functionality,
is that going to help in overcoming the concerns raised by committer
which I understand was mainly about code duplication, improvement
in messages and comments in code or am I missing something?


With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com



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

Предыдущее
От: Andreas Karlsson
Дата:
Сообщение: Re: PoC: Partial sort
Следующее
От: Amit Kapila
Дата:
Сообщение: Re: [BUG FIX] Compare returned value by socket() against PGINVALID_SOCKET instead of < 0