Re: plpgsql_check_function - rebase for 9.3 - Mailing list pgsql-hackers

From Amit Kapila
Subject Re: plpgsql_check_function - rebase for 9.3
Date
Msg-id CAA4eK1KvPYLVRzcKmrjhKOO_LEju_KBuRj_q1hjCqcg4D6kVYg@mail.gmail.com
Whole thread Raw
In response to Re: plpgsql_check_function - rebase for 9.3  (Pavel Stehule <pavel.stehule@gmail.com>)
Responses Re: plpgsql_check_function - rebase for 9.3
List pgsql-hackers
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
>> > -
>> > 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)?
>>
>
> 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.

Thanks for clarification, the part of name 'newer' has created
confusion. I understand
that creating/identifying dependency in some of the cases will be
quite tricky, does other
similar languages for other databases does that for all cases (objects
in dynamic statements).

Is the main reason for identifying/creating dependency is to mark
function as invalid when
any dependent object is Dropped/Altered?

This thread is from quite some time, so please excuse me if I had
asked anything which has
been discussed previously.

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



pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: [patch] Adding EXTRA_REGRESS_OPTS to all pg_regress invocations
Next
From: Bruce Momjian
Date:
Subject: Re: [RFC] Shouldn't we remove annoying FATAL messages from server log?