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

From: Amit kapila <amit(dot)kapila(at)huawei(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Proposal for Allow postgresql.conf values to be changed via SQL
Date: 2012-12-02 05:48:25
Message-ID: 6C0B27F7206C9E4CA54AE035729E9C383BEA0670@szxeml509-mbx
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


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.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Alastair Turner 2012-12-02 11:37:17 Patch for checking file parameters to psql before password prompt
Previous Message Amit kapila 2012-12-02 05:19:34 Re: Proposal for Allow postgresql.conf values to be changed via SQL