I'm going to be mostly unavailable till Wednesday, but I'll leave
you with another thing to chew on:
regression=# create user joe;
CREATE ROLE
regression=# grant set on parameter plpgsql.extra_warnings to joe;
ERROR: unrecognized configuration parameter "plpgsql.extra_warnings"
This is problematic, because once plpgsql is loaded it works:
regression=# load 'plpgsql';
LOAD
regression=# grant set on parameter plpgsql.extra_warnings to joe;
GRANT
If we then do
$ pg_dumpall -g
it falls over:
pg_dumpall: error: query failed: ERROR: unrecognized configuration parameter "plpgsql.extra_warnings"
apparently because aclparameterdefault() is allergic to being asked about
unknown GUCs, and plpgsql is not loaded in pg_dumpall's session. But
if pg_dumpall hadn't failed, it'd produce a dump script containing that
same command, which would fail at load time (because, again, plpgsql
isn't going to be loaded in the backend reading the restore script).
This is what I meant by saying that you can't just refuse to GRANT on
unknown GUCs. It makes custom GUCs into a time bomb for dump/restore.
And that means you need a strategy for dealing with the possibility
that you don't know whether the GUC is USERSET or not. I think though
that it might work to just assume that it isn't, in which case dumps
on unrecognized GUCs that really are USERSET will end up issuing an
explicit GRANT SET TO PUBLIC that we didn't actually need to do, but it
won't hurt anything. (Testing that assertion would be a good thing
to do.)
regards, tom lane
