From: | Magnus Hagander <magnus(at)hagander(dot)net> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Should we get rid of custom_variable_classes altogether? |
Date: | 2011-10-03 08:30:32 |
Message-ID: | CABUevEzwQuKJGxWGkwxjqHbnePp3GS09-je_BSng7vQ+2wUVqQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sun, Oct 2, 2011 at 23:05, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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/
From | Date | Subject | |
---|---|---|---|
Next Message | Florian Pflug | 2011-10-03 08:30:55 | Re: pg_dump issues |
Previous Message | Kohei KaiGai | 2011-10-03 08:25:57 | Re: [v9.2] Object access hooks with arguments support (v1) |