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