From: | "Albe Laurenz" <laurenz(dot)albe(at)wien(dot)gv(dot)at> |
---|---|
To: | "Tom Lane *EXTERN*" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | "Pavel Stehule" <pavel(dot)stehule(at)gmail(dot)com>, "PostgreSQL Hackers" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: review: CHECK FUNCTION statement |
Date: | 2011-12-02 10:52:19 |
Message-ID: | D960CB61B694CF459DCFB4B0128514C207347BCC@exadv11.host.magwien.gv.at |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tom Lane wrote:
>> Do I understand right that the reason why the check function is
>> different from the validator function is that it would be more
difficult
>> to add the checks to the validator function?
>
>> Is that a good enough argument? From a user's perspective it is
>> difficult to see why some checks are performed at function creation
>> time, while others have to be explicitly checked with CHECK FUNCTION.
>> I think it would be much more intuitive if CHECK FUNCTION does
>> the same as function validation with check_function_bodies on.
>
> I think the important point here is that we need to support more than
> one level of validation, and that the higher levels can't really be
> applied by default in CREATE FUNCTION because they may fail on
perfectly
> valid code.
I understand now.
There are three levels of checking:
1) Validation with check_function_bodies = off (checks nothing).
2) Validation with check_function_bodies = on (checks syntax).
3) CHECK FUNCTION (checks RAISE and objects referenced in the function).
As long as 3) implies 2) (which I think it does), that makes sense.
I guess I was led astray by the documentation in plhandler.sgml:
Validator functions should typically honor the check_function_bodies
parameter: [...] this parameter is turned off by pg_dump so that it
can load procedural language functions without worrying about possible
dependencies of the function bodies on other database objects.
"Dependencyies on other database objects" seems more like a description
of CHECK FUNCTION.
But I guess that this documentation should be changed anyway to describe
the check function.
> A bigger issue is that once you think about more than one kind of
check,
> it becomes apparent that we might need some user-specifiable options
to
> control which checks are applied. And I see no provision for that
here.
My attempt at a syntax that could also cover Peter's wish for multiple
checker functions:
CHECK FUNCTION { func(args) | ALL [IN SCHEMA schema] [FOR ROLE user] }
[ USING check_function ] OPTIONS (optname optarg [, ...])
Yours,
Laurenz Albe
From | Date | Subject | |
---|---|---|---|
Next Message | Alexander Korotkov | 2011-12-02 11:48:59 | Re: GiST for range types (was Re: Range Types - typo + NULL string constructor) |
Previous Message | Peter Eisentraut | 2011-12-02 10:14:17 | Re: review: CHECK FUNCTION statement |