On Wed, Jan 1, 2014 at 12:52 AM, Pavel Stehule <pavel.steh...@gmail.com> wrote: > 2013/12/31 Alvaro Herrera <alvhe...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
