Re: poll: CHECK TRIGGER?

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Alvaro Herrera <alvherre(at)commandprompt(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: poll: CHECK TRIGGER?
Date: 2012-03-05 16:41:10
Message-ID: 12653.1330965670@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

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.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Simon Riggs 2012-03-05 16:46:38 Re: RFC: Making TRUNCATE more "MVCC-safe"
Previous Message Heikki Linnakangas 2012-03-05 16:34:57 Re: Scaling XLog insertion (was Re: Moving more work outside WALInsertLock)