I think the way we're passing down the options to the checker is a bit
of a mess.  The way it is formulated, it seems to me that we'd need to
add support code in the core CheckFunction for each option we might want
to accept in the PL-specific checkers -- including what type of value
the option receives.  As an example, right now we have all but one
option taking a string argument (judging from usage of defGetString());
however, option fatal_errors takes a boolean value, and it converts to
string "on" or "off" which is supposed to be passed down to the checker.

This doesn't seem very future-proof.

(Also, the patch seems to be passing the fatal_errors value twice: first
in the options array, where it is ignored by the plpgsql checker, and a
second time as a separate boolean option.  This needs a cleanup).

I don't see any good way to pass down generic options in a generic way.
Maybe we can just state that all option values are going to be passed as
strings -- is that good enough?  The other option would be to pass them
using something like pg_node_tree, but then it wouldn't be possible to
call the checker directly instead of through CHECK FUNCTION, which I
think was a requirement.  And it'd be a stronger argument against usage
of SPI to call the checker function from CHECK FUNCTION, but that's an
unsolved problem.

-- 
Álvaro Herrera <alvherre(at)commandprompt(dot)com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

In response to

• Re: review: CHECK FUNCTION statement at 2012-02-29 13:37:48 from Pavel Stehule

Responses

• Re: review: CHECK FUNCTION statement at 2012-02-29 20:25:30 from Pavel Stehule

pgsql-hackers by date

Next:	From: Robert Haas	Date: 2012-02-29 19:02:42
	Subject: Re: Parameterized-path cost comparisons need some work
Previous:	From: Tom Lane	Date: 2012-02-29 18:40:05
	Subject: Re: Parameterized-path cost comparisons need some work