On Mon, Sep 23, 2013 at 7:06 PM, Alvaro Herrera <alvhe...@2ndquadrant.com> wrote: > I think the idea that we should consider a different way of handling > tabular configuration data has merit. In fact, how much sense does it > make to have these options (the ones for which this patch is being > written) be GUCs in the first place?
This is mainly for Customized option and or that it depends on user, how he wants to name the variables. > ALTER USER/DATABASE don't work for > them, they can't be usefully changed in the commandline, there's no > working SET. Do you mean to say that it doesn't work for SET command? As it is discussed upthread that if it works for set_config()/SET,.. so it is better that it should be allowed through postgresql.conf > If we had some way to plug these into pg_hba.conf parsing machinery > (which is tabular data), I would suggest that. But that doesn't sound > really sensible. I think the idea of putting this configuratio data > in a separate file, and perhaps a more convenient format than > three-level GUC options, should be considered. This will be really better if we can figure out a more sophisticated way to handle, but I think if it currently works with other mechanism's of GUC settings (set_config,SET, etc.), then what is the harm in allowing it through postgresql.conf file? With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
