is_superuser versus set_config_option's parallelism check

I came across this misbehavior:

regression=# create or replace function foo() returns text as
$$select current_setting('role')$$ language sql
parallel safe set role = postgres;
CREATE FUNCTION
regression=# select foo();
foo
----------
postgres
(1 row)

regression=# set debug_parallel_query to 1;
SET
regression=# select foo();
ERROR: cannot set parameters during a parallel operation
CONTEXT: parallel worker

What is failing is the attempt to update the "is_superuser" GUC
as a side-effect of setting "role". That's coming from here:

/*
* GUC_ACTION_SAVE changes are acceptable during a parallel operation,
* because the current worker will also pop the change. We're probably
* dealing with a function having a proconfig entry. Only the function's
* body should observe the change, and peer workers do not share in the
* execution of a function call started by this worker.
*
* Other changes might need to affect other workers, so forbid them.
*/
if (IsInParallelMode() && changeVal && action != GUC_ACTION_SAVE)
// throw error

Since we're using GUC_ACTION_SET to set "is_superuser", this spits up.

The simplest fix would be to hack this test to allow the action anyway
when context == PGC_INTERNAL, excusing that as "assume the caller
knows what it's doing". That feels pretty grotty though. Perhaps
a cleaner way would be to move this check to some higher code level,
but I'm not sure where would be a good place.

Thoughts?

regards, tom lane