Re: Proposal for Allow postgresql.conf values to be changed via SQL - Mailing list pgsql-hackers

From Amit Kapila
Subject Re: Proposal for Allow postgresql.conf values to be changed via SQL
Date
Msg-id 00ae01cdd36c$1ac4db90$504e92b0$@kapila@huawei.com
Whole thread Raw
In response to Re: Proposal for Allow postgresql.conf values to be changed via SQL  (Cédric Villemain <cedric@2ndquadrant.com>)
List pgsql-hackers
On Tuesday, December 04, 2012 8:37 AM Amit Kapila wrote:
> On Monday, December 03, 2012 8:59 PM Tom Lane wrote:
> > Robert Haas <robertmhaas@gmail.com> writes:
> > > On Sat, Dec 1, 2012 at 11:45 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> > >>> But even if we can't make that work, it's not grounds for
> reserving
> > >>> PERSISTENT.  Instead I'd be inclined to forget about "RESET
> > > I think this feature is more analagous to ALTER DATABASE .. SET or
> > > ALTER ROLE .. SET.  Which is, incidentally, another reason I don't
> > > like SET PERSISTENT as a proposed syntax.  But even if we stick with
> > > that syntax, it feels weird to have an SQL command to put a line
> into
> > > postgresql.conf.auto and no syntax to take it back out again.
> >
> > Neither of you have responded to the point about what "SET PERSISTENT
> > var_name TO DEFAULT" will do, and whether it is or should be different
> > from RESET PERSISTENT, and if not why we should put the latter into
> > the grammar as well.
> 
> 
> The current behavior is
> 1. "RESET PERSISTENT ..."  will delete the entry from
> postgresql.auto.conf
> 2. "SET PERSISTENT... TO DEFAULT"  will update the entry value in
> postgresql.auto.conf to default value
> 
> However we can even change "SET PERSISTENT... TO DEFAULT" to delete the
> entry and then we can avoid "RESET PERSISTENT ..."

As per my understanding from the points raised by you, the behavior could be
defined as follows:

1. No need to have "RESET PERSISTENT ..." syntax.
2. It is better if we provide a way to delete entry which could be done for
syntax:  "SET PERSISTENT... TO DEFAULT" 

If you don't have any objections, I will update the patch as per above 2
points.


With Regards,
Amit Kapila.   




pgsql-hackers by date:

Previous
From: Kyotaro HORIGUCHI
Date:
Subject: [BUG?] lag of minRecoveryPont in archive recovery
Next
From: Shigeru Hanada
Date:
Subject: Re: PATCH: optimized DROP of multiple tables within a transaction