On Mon, Sep 23, 2013 at 7:06 PM, Alvaro Herrera
<alvherre@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
