Re: plpgsql_check_function - rebase for 9.3
От | Pavel Stehule |
---|---|
Тема | Re: plpgsql_check_function - rebase for 9.3 |
Дата | |
Msg-id | CAFj8pRA09FsRLA=wSkmM0MwVBs5B5f6dLTLgYKCFzfA-1850zw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: plpgsql_check_function - rebase for 9.3 (Amit Kapila <amit.kapila16@gmail.com>) |
Ответы |
Re: plpgsql_check_function - rebase for 9.3
Re: plpgsql_check_function - rebase for 9.3 |
Список | pgsql-hackers |
2013/12/9 Amit Kapila <amit.kapila16@gmail.com>
On Sun, Dec 8, 2013 at 10:31 PM, Pavel Stehule <pavel.stehule@gmail.com> wrote:what exactly check_newer means, does it mean whenever a function is
>
>
>
> 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
replaced (changed)?
no, it means, so request for check will be ignored ever - some functions cannot be deeply checked due using dynamic SQL or dynamic created data types - temporary tables created in functions.
Regards
Pavel
> But still I have no idea, how to push check without possible slowdownWith Regards,
> execution with code duplication
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: