Re: plpgsql_check_function - rebase for 9.3

2013/12/9 Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>

> On Sun, Dec 8, 2013 at 10:31 PM, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
> wrote:
> >
> >
> >
> > 2013/12/8 Peter Eisentraut <peter_e(at)gmx(dot)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)?
>
>
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 slowdown
> > execution with code duplication
>
>
> With Regards,
> Amit Kapila.
> EnterpriseDB: http://www.enterprisedb.com
>