Robert Haas <robertmhaas@gmail.com> writes:
> Just to be clear, I am not proposing that we get rid of CHECK TRIGGER
> and keep CHECK FUNCTION. I'm proposing that we get rid of all of the
> dedicated syntax support, and expose it all through one or more
> SQL-callable functions.
This seems entirely reasonable to me. The syntax support is not the
value-add in this patch, and it's been clear since day one that it would
be difficult for the syntax to cover all the likely permutations of
"which functions do you want to check?". A function-based interface
seems like both less work and more functionality. Yes, it's marginally
less convenient for simple cases, but I'm not even sure that we know
which "simple cases" are going to be popular. We can and should
postpone that decision until we have some field experience to base it on.
> If we need both
> plpgsql_check_function(procoid) and plpgsql_check_trigger(tgoid), no
> problem.
FWIW, I would suggest check_trigger(regclass, name) not tgoid, because
we do not have a regtrigger convenience type (and I don't think it's
worth adding one).
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.
regards, tom lane