Re: pgsql-server/ oc/src/sgml/runtime.sgml rc/back ...

Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> The point of this feature is to avoid failures because of forward
> references in SQL code. A syntax-checking validator in anything but
> possibly plpgsql will not even look at SQL code, so a validator for
> a different language will only gain pain and confusion by respecting this
> parameter. Perhaps it needs to different name altogether, along the lines
> of "do not check SQL code in functions".

Well, I'm certainly not wedded to the name "check_function_bodies", but
I still feel that you're taking an overly narrow view of the future
functionality of this switch. The existing reason for having the switch
is not only to avoid forward-reference problems; it also is needed to
avoid search-path problems (eg, if the function assumes "public" is in
the search path, which it won't be during pg_restore). I think that
issues like these are likely to arise for other sorts of checks than
those on embedded SQL code. For example, it probably wouldn't be
unreasonable for a validator for brand-X-language to try to check the
existence of referenced functions, even if those functions are called
from code that doesn't look much like SQL.

We could use "check_sql_code" or some such, and it might be an accurate
description of what the switch does today, but I think we'd end up
having to either change the switch name or add more switches of the same
kind in future to cover other checks that turn out to be not always
applicable. I'd prefer to use a deliberately somewhat vague name to
improve the odds that we don't have to do that.

Would you like it better if the switch were called
do_all_the_right_things_for_pg_dump? (That name is a bit facetious,
but in terms of long-term behavior that's pretty much what I'm after.)

regards, tom lane