Re: poll: CHECK TRIGGER?

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

2012/3/5 Robert Haas <robertmhaas(at)gmail(dot)com>:
> On Mon, Mar 5, 2012 at 11:41 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>>> I confess to some bafflement about why we need dedicated syntax for
>>> this, or even any kind of core support at all.  What would be wrong
>>> with defining a function that takes regprocedure as an argument and
>>> does whatever?  Sure, it's nicer syntax, but we've repeatedly rejected
>>> patches that only provided nicer syntax on the grounds that syntax is
>>> not free, and therefore syntax alone is not a reason to change the
>>> core grammar.  What makes this case different?
>>
>> There's definitely something to be said for that, since it entirely
>> eliminates the problem of providing wildcards and control over which
>> function(s) to check --- the user could write a SELECT from pg_proc
>> that slices things however he wants.
>> The trigger case would presumably take arguments matching pg_trigger's
>> primary key, viz check_trigger(trig_rel regclass, trigger_name name).
>
> Yes...
>
>> But as for needing "core support", we do need to extend the API for PL
>> validators, so it's not like this could be done as an external project.
>
> Well, the plpgsql extension could install a function
> pg_check_plpgsql_function() that only works on PL/pgsql functions, and
> other procedural languages could do the same at their option.  I think
> we only need to extend the API if we want to provide a dispatch
> function so that you can say "check this function, whatever language
> it's written in" and have the right checker get called.  But since
> we've already talked about the possibility of having more than one
> checker per language doing different kinds of checks, I'm not even
> sure that "the checker" for a language is a concept that we want to
> invent.

There is not multiple PL checker function - or I don't know about it.

Pavel

>
> --
> Robert Haas
> EnterpriseDB: http://www.enterprisedb.com
> The Enterprise PostgreSQL Company
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2012-03-05 18:11:41 Re: review: CHECK FUNCTION statement
Previous Message Tom Lane 2012-03-05 18:02:35 Re: Parameterized-path cost comparisons need some work