Re: Proposal for Allow postgresql.conf values to be changed via SQL - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Proposal for Allow postgresql.conf values to be changed via SQL
Date
Msg-id CA+Tgmoaqb_sWzEVLju85vBsmDOMsSFUH_xUQ8pzK+8=kEQUx5A@mail.gmail.com
Whole thread Raw
In response to Re: Proposal for Allow postgresql.conf values to be changed via SQL  (Josh Berkus <josh@agliodbs.com>)
Responses Re: Proposal for Allow postgresql.conf values to be changed via SQL  (Andres Freund <andres@2ndquadrant.com>)
Re: Proposal for Allow postgresql.conf values to be changed via SQL  (Amit Kapila <amit.kapila@huawei.com>)
List pgsql-hackers
On Wed, Nov 7, 2012 at 2:50 PM, Josh Berkus <josh@agliodbs.com> wrote:
>> Well, Magnus' proposed implementation supposed that the existing values
>> *have* been loaded into the current session.  I agree that with some
>> locking and yet more code you could implement it without that.  But this
>> still doesn't seem to offer any detectable benefit over value-per-file.
>
> Well, value-per-file is ugly (imagine you've set 40 different variables
> that way) but dodges a lot of complicated issues.  And I suppose "ugly"
> doesn't matter, because the whole idea of the auto-generated files is
> that users aren't supposed to look at them anyway.

That's pretty much how I feel about it, too.  I think value-per-file
is an ugly wimp-out that shouldn't really be necessary to solve this
problem.  It can't be that hard to rewrite a file where every like is
of the form:

key = 'value'

However, as Josh said upthread, +1 for the implementation that will
get committed.

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



pgsql-hackers by date:

Previous
From: Josh Berkus
Date:
Subject: Re: Proposal for Allow postgresql.conf values to be changed via SQL
Next
From: Andres Freund
Date:
Subject: Re: Proposal for Allow postgresql.conf values to be changed via SQL