2012/3/7 Tom Lane <tgl@sss.pgh.pa.us>:
> 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.
I am able to drop all coded functionality and preparing these simple
check function is relative simple work. But I am not sure if we can
design better interface in future. It is relative well designed and
consistent with other statements.
I know so you and Robert are busy, but if you can have a 10 minutes,
try it play with it. There are nice autocomplete and "well" output. It
working well in psql.
Regards
Pavel
>
> regards, tom lane
