Re: plpgsql_check_function - rebase for 9.3
От | Amit Kapila |
---|---|
Тема | Re: plpgsql_check_function - rebase for 9.3 |
Дата | |
Msg-id | CAA4eK1LdVcNdTbkKnJvdWTP1B+V=K4Y1R9qakgXCm68z3vRirA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: plpgsql_check_function - rebase for 9.3 (Pavel Stehule <pavel.stehule@gmail.com>) |
Ответы |
Re: plpgsql_check_function - rebase for 9.3
|
Список | pgsql-hackers |
On Sun, Dec 8, 2013 at 10:31 PM, Pavel Stehule <pavel.stehule@gmail.com> wrote: > > > > 2013/12/8 Peter Eisentraut <peter_e@gmx.net> >> >> In my opinion, the idea of having a separate lint checker for a language >> is antiquated. If there are problems, they should be diagnosed at >> compile time or run time. You can add options about warning levels or >> strictness if there are concerns about which diagnostics are >> appropriate. > > > There are two points, that should be solved > > a) introduction a dependency to other object in schema - now CREATE FUNCTION > is fully independent on others > > b) slow start - if we check all paths on start, then start can be slower - > and some functions should not work due dependency on temporary tables. > > I am thinking about possible marking a function by #option (we have same > idea) > > some like > > #option check_on_first_start > #option check_on_create > #option check_newer what exactly check_newer means, does it mean whenever a function is replaced (changed)? > But still I have no idea, how to push check without possible slowdown > execution with code duplication With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: