Re: Proposal for Allow postgresql.conf values to be changed via SQL

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(at)gmail(dot)com> writes:
> > > On Sat, Dec 1, 2012 at 11:45 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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.