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

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
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:19:41
Message-ID: CA+TgmoZH6nM_1ojDLgBD66iZ3n2TR=bXPwN==jBSW5E2Nek54g@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2012-12-03 15:21:12 Re: Proposal for Allow postgresql.conf values to be changed via SQL
Previous Message Markus Wanner 2012-12-03 15:17:37 Re: Review: Extra Daemons / bgworker