Re: poll: CHECK TRIGGER?

From: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Alvaro Herrera <alvherre(at)commandprompt(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: poll: CHECK TRIGGER?
Date: 2012-03-08 07:35:42
Message-ID: CAFj8pRD-jMMn-ebPMarXPpPvV2mK6fRBwyLx_kAxdXW3GLpyAQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hello

2012/3/7 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> Just to be clear, I am not proposing that we get rid of CHECK TRIGGER
>> and keep CHECK FUNCTION.  I'm proposing that we get rid of all of the
>> dedicated syntax support, and expose it all through one or more
>> SQL-callable functions.
>
> This seems entirely reasonable to me.  The syntax support is not the
> value-add in this patch, and it's been clear since day one that it would
> be difficult for the syntax to cover all the likely permutations of
> "which functions do you want to check?".  A function-based interface
> seems like both less work and more functionality.  Yes, it's marginally
> less convenient for simple cases, but I'm not even sure that we know
> which "simple cases" are going to be popular.  We can and should
> postpone that decision until we have some field experience to base it on.
>
>> If we need both
>> plpgsql_check_function(procoid) and plpgsql_check_trigger(tgoid), no
>> problem.
>
> FWIW, I would suggest check_trigger(regclass, name) not tgoid, because
> we do not have a regtrigger convenience type (and I don't think it's
> worth adding one).
>
> More importantly, I do not agree with requiring the user to specify the
> language name --- that is, it should be check_function(procoid) and have
> that look up a language-specific checker.  Otherwise, scenarios like
> "check all my functions regardless of language" are too painful.
> There is value-added in providing that much infrastructure.

here is updated patch (with regress tests, with documentation).

I removed a CHECK FUNCTION and CHECK TRIGGER statements and replaced
it by pg_check_function and pg_check_trigger like Tom proposed.

The core of this patch is same - plpgsql checker, only user interface
was reduced.

postgres=> select pg_check_function('f2()');
pg_check_function
---------------------------------------------------------------
error:42703:3:RETURN:column "missing_variable" does not exist
Query: SELECT 'Hello' || missing_variable
-- ^
(3 rows)

postgres=> select pg_check_trigger('t','t1');
pg_check_trigger
--------------------------------------------------------
error:42703:3:assignment:record "new" has no field "b"
Context: SQL statement "SELECT new.b + 1"
(2 rows)

Regards

Pavel

>
>                        regards, tom lane

Attachment Content-Type Size
reduced_pl_checker_2012-03-08_1.patch.gz application/x-gzip 28.1 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Albe Laurenz 2012-03-08 09:49:48 Re: poll: CHECK TRIGGER?
Previous Message Kyotaro HORIGUCHI 2012-03-08 05:35:21 Re: Speed dblink using alternate libpq tuple storage