On Monday, December 03, 2012 8:50 PM Robert Haas wrote:
> On Sat, Dec 1, 2012 at 11:45 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> > I 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
> PERSISTENT"
> >> syntax and use, say, SET PERSISTENT var_name TO DEFAULT to mean that.
> >> (BTW, I wonder what behavior that syntax has now in your patch.)
> >
> > In fact, rereading this, I wonder why you think "RESET PERSISTENT"
> > is a good idea even if there were no bison issues with it. We don't
> > write RESET LOCAL or RESET SESSION, so it seems asymmetric to have
> > RESET PERSISTENT.
>
> 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. We
> wouldn't allow a CREATE command without a corresponding DROP
> operation...
Current implementation of "SET PERSISTENT... TO DEFAULT" will update the
entry value in postgresql.auto.conf to default value.
How about if make the behavior of "SET PERSISTENT... TO DEFAULT" such that
it will delete the entry in postgresql.auto.conf?
With Regards,
Amit Kapila.