On Sun, Oct 2, 2011 at 10:05 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > During the discussion of Alexey Klyukin's rewrite of ParseConfigFile, > considerable unhappiness was expressed by various people about the > complexity and relative uselessness of the custom_variable_classes GUC. > While working over his patch just now, I've come around to the side that > was saying that this variable isn't worth its keep. We don't have any > way to validate whether the second part of a qualified GUC name is > correct, if its associated extension module isn't loaded, so how much > point is there in validating the first part? And the variable is > certainly a pain in the rear both to DBAs and to the GUC code itself. > > So at this point I'd vote for just dropping it and always allowing > custom (that is, qualified) GUC names to be set, whether the prefix > corresponds to any loaded module or not.
Sounds sensible. One less thing to configure is a good thing. -- Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
