Re: plpgsql_check_function - rebase for 9.3

From: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
To: Peter Eisentraut <peter_e(at)gmx(dot)net>
Cc: Steve Singer <steve(at)ssinger(dot)info>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Josh Berkus <josh(at)agliodbs(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: plpgsql_check_function - rebase for 9.3
Date: 2013-12-08 17:01:40
Message-ID: CAFj8pRBBUF2zowRRiTUbcSCVKHaspL=+=-pBg8P2B-UXH7cjkQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

But still I have no idea, how to push check without possible slowdown
execution with code duplication

Pavel

> >
> >
> >
> >
> >
> >
> >
>
>

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2013-12-08 18:04:16 Re: WITHIN GROUP patch
Previous Message Andres Freund 2013-12-08 16:51:25 Re: Add %z support to elog/ereport?