Re: Should we get rid of custom_variable_classes altogether?
От | Magnus Hagander |
---|---|
Тема | Re: Should we get rid of custom_variable_classes altogether? |
Дата | |
Msg-id | CABUevEzwQuKJGxWGkwxjqHbnePp3GS09-je_BSng7vQ+2wUVqQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Should we get rid of custom_variable_classes altogether? (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Should we get rid of custom_variable_classes altogether?
|
Список | pgsql-hackers |
On Sun, Oct 2, 2011 at 23:05, Tom Lane <tgl@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. Don't forget that there are usecases for variables under custom_variable_classes that aren't actually associated with extensions (as general session-shared-variables). Though I guess if it was somehow restricted to extensions, those who needed that could just rewrap all their code as extensions - though that would make it less convenient. The point being that even if you *could* validate them somehow against a static list, requiring that might not be a good idea. > 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. Seems reasonable to me. -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/
В списке pgsql-hackers по дате отправления: