Commit 546f7c2e authored by Tom Lane's avatar Tom Lane

Don't fail for bad GUCs in CREATE FUNCTION with check_function_bodies off.

The previous coding attempted to activate all the GUC settings specified
in SET clauses, so that the function validator could operate in the GUC
environment expected by the function body.  However, this is problematic
when restoring a dump, since the SET clauses might refer to database
objects that don't exist yet.  We already have the parameter
check_function_bodies that's meant to prevent forward references in
function definitions from breaking dumps, so let's change CREATE FUNCTION
to not install the SET values if check_function_bodies is off.

Authors of function validators were already advised not to make any
"context sensitive" checks when check_function_bodies is off, if indeed
they're checking anything at all in that mode.  But extend the
documentation to point out the GUC issue in particular.

(Note that we still check the SET clauses to some extent; the behavior
with !check_function_bodies is now approximately equivalent to what ALTER
DATABASE/ROLE have been doing for awhile with context-dependent GUCs.)

This problem can be demonstrated in all active branches, so back-patch
all the way.
parent 0d3f4406
...@@ -200,6 +200,13 @@ CREATE LANGUAGE plsample ...@@ -200,6 +200,13 @@ CREATE LANGUAGE plsample
of having a validator is not to let the call handler omit checks, but of having a validator is not to let the call handler omit checks, but
to notify the user immediately if there are obvious errors in a to notify the user immediately if there are obvious errors in a
<command>CREATE FUNCTION</> command.) <command>CREATE FUNCTION</> command.)
While the choice of exactly what to check is mostly left to the
discretion of the validator function, note that the core
<command>CREATE FUNCTION</> code only executes <literal>SET</> clauses
attached to a function when <varname>check_function_bodies</> is on.
Therefore, checks whose results might be affected by GUC parameters
definitely should be skipped when <varname>check_function_bodies</> is
off, to avoid false failures when reloading a dump.
</para> </para>
<para> <para>
......
...@@ -668,24 +668,34 @@ ProcedureCreate(const char *procedureName, ...@@ -668,24 +668,34 @@ ProcedureCreate(const char *procedureName,
/* Verify function body */ /* Verify function body */
if (OidIsValid(languageValidator)) if (OidIsValid(languageValidator))
{ {
ArrayType *set_items; ArrayType *set_items = NULL;
int save_nestlevel; int save_nestlevel = 0;
/* Advance command counter so new tuple can be seen by validator */ /* Advance command counter so new tuple can be seen by validator */
CommandCounterIncrement(); CommandCounterIncrement();
/* Set per-function configuration parameters */ /*
set_items = (ArrayType *) DatumGetPointer(proconfig); * Set per-function configuration parameters so that the validation is
if (set_items) /* Need a new GUC nesting level */ * done with the environment the function expects. However, if
* check_function_bodies is off, we don't do this, because that would
* create dump ordering hazards that pg_dump doesn't know how to deal
* with. (For example, a SET clause might refer to a not-yet-created
* text search configuration.) This means that the validator
* shouldn't complain about anything that might depend on a GUC
* parameter when check_function_bodies is off.
*/
if (check_function_bodies)
{ {
save_nestlevel = NewGUCNestLevel(); set_items = (ArrayType *) DatumGetPointer(proconfig);
ProcessGUCArray(set_items, if (set_items) /* Need a new GUC nesting level */
(superuser() ? PGC_SUSET : PGC_USERSET), {
PGC_S_SESSION, save_nestlevel = NewGUCNestLevel();
GUC_ACTION_SAVE); ProcessGUCArray(set_items,
(superuser() ? PGC_SUSET : PGC_USERSET),
PGC_S_SESSION,
GUC_ACTION_SAVE);
}
} }
else
save_nestlevel = 0; /* keep compiler quiet */
OidFunctionCall1(languageValidator, ObjectIdGetDatum(retval)); OidFunctionCall1(languageValidator, ObjectIdGetDatum(retval));
......
...@@ -718,3 +718,19 @@ select myfunc(1), current_setting('work_mem'); ...@@ -718,3 +718,19 @@ select myfunc(1), current_setting('work_mem');
2MB | 2MB 2MB | 2MB
(1 row) (1 row)
-- Normally, CREATE FUNCTION should complain about invalid values in
-- function SET options; but not if check_function_bodies is off,
-- because that creates ordering hazards for pg_dump
create function func_with_bad_set() returns int as $$ select 1 $$
language sql
set default_text_search_config = no_such_config;
NOTICE: text search configuration "no_such_config" does not exist
ERROR: invalid value for parameter "default_text_search_config": "no_such_config"
set check_function_bodies = off;
create function func_with_bad_set() returns int as $$ select 1 $$
language sql
set default_text_search_config = no_such_config;
NOTICE: text search configuration "no_such_config" does not exist
select func_with_bad_set();
ERROR: invalid value for parameter "default_text_search_config": "no_such_config"
reset check_function_bodies;
...@@ -257,3 +257,21 @@ set work_mem = '1MB'; ...@@ -257,3 +257,21 @@ set work_mem = '1MB';
select myfunc(0); select myfunc(0);
select current_setting('work_mem'); select current_setting('work_mem');
select myfunc(1), current_setting('work_mem'); select myfunc(1), current_setting('work_mem');
-- Normally, CREATE FUNCTION should complain about invalid values in
-- function SET options; but not if check_function_bodies is off,
-- because that creates ordering hazards for pg_dump
create function func_with_bad_set() returns int as $$ select 1 $$
language sql
set default_text_search_config = no_such_config;
set check_function_bodies = off;
create function func_with_bad_set() returns int as $$ select 1 $$
language sql
set default_text_search_config = no_such_config;
select func_with_bad_set();
reset check_function_bodies;
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment