Thread: check_function_bodies: At least the description seems wrong, since we have prodedures
check_function_bodies: At least the description seems wrong, since we have prodedures
From
"Daniel Westermann (DWE)"
Date:
Hi, check_function_bodies has this description: postgres=# select short_desc from pg_settings where name = 'check_function_bodies'; short_desc ----------------------------------------------- Check function bodies during CREATE FUNCTION. (1 row) This is not the whole truth since we have procedures, as this affects CREATE PROCEDURE as well: postgres=# create procedure p1 ( a int ) as $$ beginn null; end $$ language plpgsql; ERROR: syntax error at or near "beginn" LINE 1: create procedure p1 ( a int ) as $$ beginn null; end $$ lang... ^ postgres=# set check_function_bodies = false; SET postgres=# create procedure p1 ( a int ) as $$ beginn null; end $$ language plpgsql; CREATE PROCEDURE postgres=# At least the description should mention procedures. Even the parameter name seems not to be correct anymore. Thoughts? Regards Daniel
Re: check_function_bodies: At least the description seems wrong, since we have prodedures
From
Chapman Flack
Date:
On 04/09/21 08:11, Daniel Westermann (DWE) wrote: > At least the description should mention procedures. > Even the parameter name seems not to be correct anymore. Thoughts? It's possible the parameter name also appears in documentation for out-of-tree PLs, as each PL's validator function determines what "check_function_bodies" really means in that setting. For instance, it's documented in PL/Java that check_function_bodies really means the (precompiled) class file is loaded and the presence of its dependencies and the target method confirmed. That means that any change to the parameter name could result in some documentation churn in the extension world. Regards, -Chap
Re: check_function_bodies: At least the description seems wrong, since we have prodedures
From
Tom Lane
Date:
Chapman Flack <chap@anastigmatix.net> writes: > On 04/09/21 08:11, Daniel Westermann (DWE) wrote: >> At least the description should mention procedures. >> Even the parameter name seems not to be correct anymore. Thoughts? > It's possible the parameter name also appears in documentation for > out-of-tree PLs, as each PL's validator function determines what > "check_function_bodies" really means in that setting. That parameter is also set explicitly in pg_dump output, so we can't rename it without breaking existing dump files. Admittedly, guc.c does have provisions for substituting new names if we rename some parameter. But I'm not in a hurry to create more instances of that behavior; the potential for confusion seems to outweigh any benefit. +1 for updating the description though. We could s/function/routine/ where space is tight. regards, tom lane
Re: check_function_bodies: At least the description seems wrong, since we have prodedures
From
"Daniel Westermann (DWE)"
Date:
>> It's possible the parameter name also appears in documentation for >> out-of-tree PLs, as each PL's validator function determines what >> "check_function_bodies" really means in that setting. >That parameter is also set explicitly in pg_dump output, so we >can't rename it without breaking existing dump files. >Admittedly, guc.c does have provisions for substituting new names >if we rename some parameter. But I'm not in a hurry to create >more instances of that behavior; the potential for confusion >seems to outweigh any benefit. >+1 for updating the description though. We could s/function/routine/ >where space is tight. Thanks for your inputs. Attached a proposal which updates the description. Regards Daniel
Attachment
Re: check_function_bodies: At least the description seems wrong, since we have prodedures
From
Tom Lane
Date:
"Daniel Westermann (DWE)" <daniel.westermann@dbi-services.com> writes: >> +1 for updating the description though. We could s/function/routine/ >> where space is tight. > Thanks for your inputs. Attached a proposal which updates the description. I changed config.sgml's description similarly, and pushed this. regards, tom lane