On Saturday, December 01, 2012 10:15 PM Tom Lane 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.
Currently RESET will reset both local and session specific parameter value on commit.
I am not sure if we can change the persistent value with current RESET command.
However as you said if we introduce PERSISTENT it will be asymmetric as per current specification of RESET command,
so we can even let RESET behavior as it is and user will have mechanism to change default value only with
SET PERSISTENT var_name TO DEFAULT.
With Regards,
Amit Kapila.
