Re: poll: CHECK TRIGGER? - Mailing list pgsql-hackers

From Tom Lane
Subject Re: poll: CHECK TRIGGER?
Date
Msg-id 15958.1331146998@sss.pgh.pa.us
Whole thread Raw
In response to Re: poll: CHECK TRIGGER?  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: poll: CHECK TRIGGER?  (Pavel Stehule <pavel.stehule@gmail.com>)
Re: poll: CHECK TRIGGER?  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> On Wed, Mar 7, 2012 at 12:04 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> 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.

> I might agree with you if we had more than one checker function, but
> right now we are proposing to implement this for PL/pgsql and only
> PL/pgsql.  It seems to me that we can add that when and if a second
> checker function shows up, if it still seems like a good idea.

That argument is just silly.  The only reason there's only one checker
function is that that's all Pavel has bothered to write yet, and all
that he's likely to write since (AFAICT) he doesn't care about the other
PLs.  But other people do.  There is certainly value in being able to do
checking of other languages, and if we don't set this up properly now,
we're going to have problems with having to change the user-visible API
later.

I said from the beginning that I thought the most important part of this
patch was getting the API for the language-specific validator functions
right, and I remain of that opinion.  If we're going to blow that off
then we should forget the patch entirely until we have time to do it
right.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Daniel Farina
Date:
Subject: Re: pg_stat_statements and planning time
Next
From: Simon Riggs
Date:
Subject: Re: RFC: Making TRUNCATE more "MVCC-safe"