Re: plpgsql_check_function - rebase for 9.3

Поиск
Список
Период
Сортировка
От Amit Kapila
Тема Re: plpgsql_check_function - rebase for 9.3
Дата
Msg-id CAA4eK1JiiEH-sF6JyOK5GFh_iZE0pQafmKJLxPy4=RNc3gxVEA@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 Tue, Dec 10, 2013 at 12:15 PM, Pavel Stehule <pavel.stehule@gmail.com> wrote:
> 2013/12/10 Amit Kapila <amit.kapila16@gmail.com>
>> On Mon, Dec 9, 2013 at 10:54 AM, Pavel Stehule <pavel.stehule@gmail.com>
>> wrote:
>> > 2013/12/9 Amit Kapila <amit.kapila16@gmail.com>
>> >> > 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
>>>>
>> >> > 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)?
>> >>
>> >
>> > 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.
>>
>
>
> Now, PG has no any tool for checking dependency between functions and other
> objects. What has positive effects - we have very simply deploying, that
> works in almost use cases very well - and works with our temporary tables
> implementation. There is simple rule - depended object must living before
> they are >>used in runtime<<. But checking should not be runtime event and
> we would to decrease a false alarms. So we have to expect so almost all
> necessary object are created - it is reason, why we decided don't do check
> in create function statement time.

Isn't that already done for SQL function's (fmgr_sql_validator)?

postgres=# CREATE FUNCTION clean_emp() RETURNS void AS
postgres'#     DELETE FROM emp
postgres'#         WHERE salary < 0;
postgres'# ' LANGUAGE SQL;
ERROR:  relation "emp" does not exist
LINE 2:     DELETE FROM emp                       ^

I mean to say that the above rule stated by you ("There is simple rule
- depended object must living before
they are >>used in runtime<<") doesn't seem to be true for SQL functions.
So isn't it better to do same for plpgsql functions as well?

For doing at runtime (during first execution of function) are you
planing to add it as a extra step
such that if parameter check_on_first_start is set, then do it.

>We don't would to introduce new dependency if it will be possible. In that case what exactly you mean to say in point
a)("introduction
 
a dependency to other object..") above in you mail.

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



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

Предыдущее
От: KONDO Mitsumasa
Дата:
Сообщение: Re: Why we are going to have to go DirectIO
Следующее
От: Fujii Masao
Дата:
Сообщение: Re: -d option for pg_isready is broken