On Mon, Sep 21, 2009 at 1:32 PM, Josh Berkus <j...@agliodbs.com> wrote: > >>> I think that if the use case for a GUC is to set it, run a single very >>> specific statement, and then unset it, that is pretty clear evidence that >>> this should not be a GUC in the first place. > > +1 > > Plus, do we really want another GUC?
Well, I don't share the seemingly-popular sentiment that more GUCs are a bad thing. GUCs let you change important parameters of the application without compiling, which is very useful. Of course, I don't want: - GUCs that I'm going to set, execute one statement, and the unset (and this likely falls into that category). - GUCs that are poorly designed so that it's not clear, even to an experienced user, what value to set. - GUCs that exist only to work around the inability of the database to figure out the appropriate value without user input. On the flip side, rereading the thread, one major advantage of the GUC is that it can be used for statements other than SELECT, which hard-coded syntax can't. That might be enough to make me change my vote. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
