Should we get rid of custom_variable_classes altogether? - Mailing list pgsql-hackers

From Tom Lane
Subject Should we get rid of custom_variable_classes altogether?
Date
Msg-id 922.1317589538@sss.pgh.pa.us
Whole thread Raw
Responses Re: Should we get rid of custom_variable_classes altogether?  (Simon Riggs <simon@2ndQuadrant.com>)
Re: Should we get rid of custom_variable_classes altogether?  (Magnus Hagander <magnus@hagander.net>)
Re: Should we get rid of custom_variable_classes altogether?  (Alex Shulgin <alex.shulgin@gmail.com>)
List pgsql-hackers
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


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: REVIEW proposal: a validator for configuration files
Next
From: Joe Abbate
Date:
Subject: Re: pg_dump issues