On Saturday, December 01, 2012 10:00 PM Tom Lane wrote:
Amit Kapila <amit.kapila@huawei.com> writes :
> On Saturday, December 01, 2012 1:30 AM Tom Lane wrote:
>>> But having said that, it's not apparent to me why inventing SET
>>> PERSISTENT should require reserving PERSISTENT.
>> The problem is due to RESET PERSISTENT configuration_variable Syntax.
>> I think the reason is that configuration_variable name can also be
>> persistent, so its not able to resolve.
> 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.)
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
The discussion for this is at below link:
http://archives.postgresql.org/pgsql-hackers/2012-11/msg01276.php
I am not too keen to have RESET Persistent, but the only point of keeping it was that it can give user flexibility that
it
can have the values to take effect from postgresql.conf even if user has executed SET Persistent.
Apart from this also user can do that by putting the configuration variable after include_dir in postgresql.conf.
With Regards,
Amit Kapila.
