Re: poll: CHECK TRIGGER?
От | Pavel Stehule |
---|---|
Тема | Re: poll: CHECK TRIGGER? |
Дата | |
Msg-id | CAFj8pRD-jMMn-ebPMarXPpPvV2mK6fRBwyLx_kAxdXW3GLpyAQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: poll: CHECK TRIGGER? (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: poll: CHECK TRIGGER?
|
Список | pgsql-hackers |
Hello 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. here is updated patch (with regress tests, with documentation). I removed a CHECK FUNCTION and CHECK TRIGGER statements and replaced it by pg_check_function and pg_check_trigger like Tom proposed. The core of this patch is same - plpgsql checker, only user interface was reduced. postgres=> select pg_check_function('f2()'); pg_check_function --------------------------------------------------------------- error:42703:3:RETURN:column "missing_variable" does not exist Query: SELECT 'Hello' || missing_variable -- ^ (3 rows) postgres=> select pg_check_trigger('t','t1'); pg_check_trigger -------------------------------------------------------- error:42703:3:assignment:record "new" has no field "b" Context: SQL statement "SELECT new.b + 1" (2 rows) Regards Pavel > > regards, tom lane
Вложения
В списке pgsql-hackers по дате отправления: