Re: [RFC] Extend namespace of valid guc names - Mailing list pgsql-hackers

From Amit Kapila
Subject Re: [RFC] Extend namespace of valid guc names
Date
Msg-id CAA4eK1+neku4V4BDOBJGmsK5AfoksZ=-QFZbqXV3ZXPeEYFovg@mail.gmail.com
Whole thread Raw
In response to Re: [RFC] Extend namespace of valid guc names  (Alvaro Herrera <alvherre@2ndquadrant.com>)
List pgsql-hackers
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



pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: Completing PL support for Event Triggers
Next
From: Chris Travers
Date:
Subject: Re: 9.3 Json & Array's