Re: poll: CHECK TRIGGER?

On Wed, Mar 7, 2012 at 2:03 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> On Wed, Mar 7, 2012 at 12:04 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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.

If we publish plpgsql_check(regproc) now and a year from now we
publish anypl_check(regproc), the former will still work. There's no
need for an API break there.

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

Well, I guess I'm still of the opinion that the real question is
whether the particular lint checks that Pavel's implemented are good
and useful things. Has anyone spent any time looking at *that*? I'm
not going to stand here and hold my breath over the interface, but it
seems to me that if we don't know that we've got a worthwhile set of
underlying functionality, sweating the interface too much is putting
the cart before the horse.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company