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 statement. 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 Pavel > > regards, tom lane > -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
