Should we get rid of custom_variable_classes altogether?

Поиск
Список
Период
Сортировка
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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: REVIEW proposal: a validator for configuration files
Следующее
От: Joe Abbate
Дата:
Сообщение: Re: pg_dump issues