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
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 |