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. Comments, other proposals? regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers