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

2012/3/9 Tom Lane <tgl@sss.pgh.pa.us>:
> Pavel Stehule <pavel.stehule@gmail.com> writes:
>> 2012/3/9 Peter Eisentraut <peter_e@gmx.net>:
>>> What would be the qualifications for being an internal or an external
>>> checker?  Why couldn't your plpgsql checker be an external checker?
>
>> plpgsql checker cannot be external checker, because it reuse 70% of
>> plpgsql environment, - parser, runtime, ...
>
> Well, that just means that it'd be a good idea for that function to be
> supplied by the same shared library that supplies the plpgsql execution
> functions.  There wouldn't need to be any connection that the core
> system particularly understands.  So, like Peter, I'm not quite sure
> what distinction is meant to be drawn by "internal" vs "external".

internal - implement in core, external - implement in extension.

This is history about this feature:

a) I wrote plgsql_lint, and I proposed it as core plpgsql functionality
b) there was request using some different then GUC, and there was
first check_function
c) there was request do it with more user friendly - there is CHECK xxx
d) there was request for support multiple checks, there is CHECK xxx ALL
e) these features was reduced - step by step,... but really important  @a

Personally I think so any form of plpgsql check is big step against
current state. We can move general check functions to plpgsql space,
and it can be good enough for plpgsql developers. It is not user
friendly like CHECK FUNCTION is it, but it has important functionality
- checking of embedded SQL without execution and without dependency on
executed paths.

I cannot to move plpgsql checker to extension, because there is
dependency on plpgsql lib, and this is problem. If I can do it, then I
did it

>
> The thing that really struck me about Peter's previous comments was the
> desire to support multiple checkers per PL.  I had been assuming that
> we'd just extend the "validator" model in some way

I tried to do it, but it is not practical - a interface of validators
is volatile now - it is different for functions and for triggers, and
it doesn't expect returning anything else than exception. More - other
new functionality can increase complexity of current plpgsql
validators. So this is reason, why I designed new handler function.

--- either another
> column in pg_language or extending the API for validator functions.
> Neither of those work if we want to allow multiple checkers.  Now,
> I'm not at all convinced that multiple checkers are worth the trouble

I don't see a reason why we need a multiple checkers - checkers are
parametrised, so there are no real reason, But what statement will be
maintain this catalog - CREATE CHECK ? You need DROP, ALTER, .. it is
lot code too.

> ... but if they are it seems like we need a different system catalog to
> store them in.  And the entries in that catalog wouldn't necessarily be
> created by the same extension that creates the PL language.

This looks like real overhead. Without user interface - like CHECK
statement, what is value of this?

I am skeptic. Can we go back and can we solve a checking just plpgsql
- it just needs integration of plpgsql checker to plpgsql runtime. Any
PL can have one or more these functions. And when we will have a
adequate user API - SQL statements (CHECK statements or some else),
then we can create a new catalog. It is strange do it in different
order.

Regards

Pavel


>
>                        regards, tom lane