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 <alvhe...@commandprompt.com> The PostgreSQL Company - Command Prompt, Inc. PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
