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.
