On Mon, Mar 5, 2012 at 11:41 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.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.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
