2011/11/30 Tom Lane <t...@sss.pgh.pa.us>:
> Pavel Stehule <pavel.steh...@gmail.com> writes:
>> 2011/11/30 Alvaro Herrera <alvhe...@commandprompt.com>:
>>> How about
>>> CHECK (parse, names=off) FUNCTION foobar(a, b, c)
>> this syntax is relative consistent with EXPLAIN, is it ok for all?
> It seems pretty awkward to me, particularly putting the options before
> the second keyword of the command --- that could bite us if we ever want
> some other flavors of CHECK command.  I prefer Robert's suggestion of a
> WITH clause at the end.

we can provide both versions - as can be fine for people. Is is simple
in parser. I like both variants and I am thinking so much more
important is a API of checker function and behave of CHECK FUNCTION

Just idea - don't kill me :). Because CHECK FUNCTION  is not
destructive , then complete signature is not necessary, and when
function name is unique, then parameters should be optional - it can
be comfortable for manual work, so just CHECK FUNCTION name; can work.
I see a usage for option - a entering  parameter's values instead
signature. When I started with overloaded functions, sometimes I had a
problem with identification of function that was executed - CHECK
FUNCTION can help

CHECK FUNCTION name(10,20) WITH (values);
Notice: checking function name(int, int, int default 20)

I would to design API of checker function be friendly to direct call.
There was some ideas to design CHECK FUNCTION for possibility to check
all functions in schema or language. It should be, but we have a
inline statement and system catalog, so anybody can write own scripts
per your requests. And It was one point to decision for separate
checker function from validate function.



>                        regards, tom lane

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to