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

From: Greg Smith <greg(at)2ndQuadrant(dot)com>
To: Greg Stark <stark(at)mit(dot)edu>
Cc: Amit Kapila <amit(dot)kapila(at)huawei(dot)com>, Andres Freund <andres(at)2ndquadrant(dot)com>, Boszormenyi Zoltan <zb(at)cybertec(dot)at>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Proposal for Allow postgresql.conf values to be changed via SQL [review]
Date: 2013-03-12 09:06:36
Message-ID: 513EF01C.7050403@2ndQuadrant.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 3/11/13 12:19 PM, Greg Stark wrote:
> Think also about the case where someone wants to change multiple
> values together and having just some set and not others would be
> inconsistent.

Isn't that an argument for syntax to make an exception though? If
starting from a blank slate I would say this case should be:

SET PERSISTENT (POSTPONE) maintenance_work_mem='2GB';
SET PERSISTENT work_mem='2GB';

That's jumping right over a few rounds of simpler ways to do this, and
just going right to the approach we know allows adding more such options
later with minimal grammar impact.

From the perspective of what a useful minimal commit looks like, I
would think 90% of the use cases here expect immediate reload of just
the postgresql.conf--but probably not pg_hba.conf--and any other
refinement could wait until a next release.

--
Greg Smith 2ndQuadrant US greg(at)2ndQuadrant(dot)com Baltimore, MD
PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Albe Laurenz 2013-03-12 09:27:02 Re: Column defaults for foreign tables (was Re: [v9.3] writable foreign tables)
Previous Message Michael Paquier 2013-03-12 07:32:57 Re: Incorrect handling of timezones with extract