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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Amit Kapila <amit(dot)kapila(at)huawei(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Proposal for Allow postgresql.conf values to be changed via SQL
Date: 2012-12-03 15:28:31
Message-ID: 12948.1354548511@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Sat, Dec 1, 2012 at 11:45 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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 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.

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.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2012-12-03 15:32:31 Re: Proposal for Allow postgresql.conf values to be changed via SQL
Previous Message Simon Riggs 2012-12-03 15:27:31 Re: Review: Extra Daemons / bgworker