Re: review: CHECK FUNCTION statement

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: review: CHECK FUNCTION statement
Дата
Msg-id 16633.1322838315@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: review: CHECK FUNCTION statement  (Peter Eisentraut <peter_e@gmx.net>)
Ответы Re: review: CHECK FUNCTION statement  (Pavel Stehule <pavel.stehule@gmail.com>)
Список pgsql-hackers
Peter Eisentraut <peter_e@gmx.net> writes:
> On ons, 2011-11-30 at 10:53 -0500, Tom Lane wrote:
>> I think the important point here is that we need to support more than
>> one level of validation, and that the higher levels can't really be
>> applied by default in CREATE FUNCTION because they may fail on perfectly
>> valid code.

> How would this work with anything other than PL/pgSQL in practice?

Well, that's TBD by the individual PL authors, but it hardly seems
implausible that there might be lint-like checks applicable in many
PLs.  As long as we have the functionality pushed out to a PL-specific
checker function, the details can be worked out later.

> So what I'd like to have is some way to say

>         check all plpythonu functions [in this schema or whatever] using
>         checker "pylint"

> where "pylint" was previously defined as a checker associated with the
> plpythonu language that actually invokes some user-defined function.

That sounds like a language-specific option to me.

> Also, what kind of report does this generate?

Good question.  I suspect what Pavel has now will raise errors, but that
doesn't scale very nicely to checking more than one function, or even to
finding more than one bug in a single function.

My first instinct is to say that it should work like plain EXPLAIN, ie,
deliver a textual report that we send as if it were a query result.
        regards, tom lane


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

Предыдущее
От: karavelov@mail.bg
Дата:
Сообщение: Re: Why so few built-in range types?
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Inlining comparators as a performance optimisation