Nico Williams <nico@cryptonector.com> writes: > With access controls, GUCs could become schema variables, and settings > from postgresql.conf could move into the database itself (which I think > would be nice).
People re-propose some variant of that every so often, but it never works, because it ignores the fact that some of the GUCs' values are needed before you can access system catalogs at all, or in places where relying on system catalog access would be a bad idea.
I think the basic point one should get here is that no matter the unification, you still have some things in the db and some things out.
I would rather look at how the GUC could be improved on a functional/use case level before we look at the question of a technical solution.
One major use case today would be restricting how high various users can set something like work_mem or the like. As it stands, there isn't really a way to control this with any granularity. So some of the proposals regarding granting access to a session variable would be very handy in granting access to a GUC variable.
Sure, we could have two completely different configuration mechanisms so that some of the variables could be "inside the database", but that doesn't seem like a net improvement to me. The point of the Grand Unified Configuration mechanism was to be unified, after all.
+1
I'm on board with having a totally different mechanism for session variables. The fact that people have been abusing GUC to store user-defined variables doesn't make it a good way to do that.
