Re: poll: CHECK TRIGGER? - Mailing list pgsql-hackers

From Pavel Stehule
Subject Re: poll: CHECK TRIGGER?
Date
Msg-id CAFj8pRDLmTnRMf+9N6tm9HAY8wVaXpvjKP4GOPfoYL+2YD7yMA@mail.gmail.com
Whole thread Raw
In response to Re: poll: CHECK TRIGGER?  (Peter Eisentraut <peter_e@gmx.net>)
Responses Re: poll: CHECK TRIGGER?
List pgsql-hackers
2012/3/8 Peter Eisentraut <peter_e@gmx.net>:
> On ons, 2012-03-07 at 12:31 -0500, Robert Haas wrote:
>> I might agree with you if we had more than one checker function, but
>> right now we are proposing to implement this for PL/pgsql and only
>> PL/pgsql.  It seems to me that we can add that when and if a second
>> checker function shows up, if it still seems like a good idea.
>
> I had mentioned upthread that I would like to use this for PL/Python.
> There are a number of code quality checkers out there for Python.  I
> currently have 3 hooked into Emacs, and 2 or 3 are typically used in the
> builds of projects I'm working on.  All of these are shipped separately
> from Python.
>
> This leads to the following requirements:
>
>      * Multiple checkers per language must be supported.
>      * It must be possible to add checkers to a language after it is
>        created.  For example, a checker could be shipped in an
>        extension.
>      * It's not terribly important to me to be able to run checkers
>        separately.  If I wanted to do that, I would just disable or
>        remove the checker.
>      * Just to make things interesting, it should be possible to
>        implement checkers for language X in language X.

But you propose some little bit different than is current plpgsql
checker and current design. You need hook on CREATE FUNCTION probably?
It's not bad, but it is some different and it is not useful for
plpgsql - external stored procedures are different, than SQL
procedures and probably you will check different issues.

I don't think so multiple checkers and external checkers are necessary
- if some can living outside, then it should to live outside. Internal
checker can be one for PL language. It is parametrized - so you can
control goals of checking.

>
> If it would help, given an API (even if only in C at the moment), I
> could probably write up one or two checker function prototypes that
> could be run against the PL/Python regression test corpus.
>

sure, please look on patch and plpgsql checker function. Checker can
be any function with same interface. Some PL/Python checker can be
good.

Regards

Pavel

>


pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: PGXS ignores SHLIB_LINK when linking modules
Next
From: Dimitri Fontaine
Date:
Subject: Re: Command Triggers, patch v11