Re: plpgsql GUC variable: custom or built-in?

I wrote:
> Fair enough.  I'll start writing the custom GUC then.

While testing that, I noticed a pre-existing GUC limitation that maybe
we should do something about now: it does not work very nicely for
custom SUSET GUC variables.  Normally, if a variable is SUSET, an
ordinary user can't do ALTER USER SET or ALTER DATABASE SET to modify
it.  However, a superuser can do that on his behalf, and then the
variable will default in the desired way for that user or database.
But this logic doesn't work for custom variables: the system doesn't
record whether the option was set by a superuser or not, so it's
afraid to allow the value to be applied when the defining module
gets loaded.  (Instead you get a WARNING and the value reverts to
default.)

I think we discussed this once before and came up with the idea that
it wouldn't be a problem if ALTER USER/DATABASE SET disallowed setting
of variables not currently known to the system.  Right now, if
plpgsql is in custom_variable_classes, you can doALTER USER foouser SET plpgsql.variable_conflict = variable_first;
and the system will take it even if plpgsql isn't loaded.  If we
required plpgsql to be loaded then we could be sure that the appropriate
permissions check had been made when the ALTER was done, and then in
subsequent sessions it would be safe to apply the variable value while
loading plpgsql.

One possible objection is that a loadable module couldn't safely upgrade
a USERSET variable to SUSET (except across a major version boundary),
since the permissions check would already have been made implicitly for
any ALTER settings.  This doesn't seem like a big problem compared to
the current situation of not being able to use SUSET effectively at all,
though.

Another issue is that pg_dumpall output would fail to reload with such a
restriction, since the dump script would most likely be executed in a
session that hadn't loaded the relevant loadable module.  We could get
around that by still allowing superusers to issue ALTER SET for unknown
variables, but that seems a tad weird.  OTOH the current rule (must be
in custom_variable_classes) is pretty hazardous for dump reloading, too.

Comments?
        regards, tom lane