Skip site navigation (1) Skip section navigation (2)

Re: SQL command to edit postgresql.conf, with comments

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Dimitri Fontaine <dimitri(at)2ndquadrant(dot)fr>, Josh Berkus <josh(at)agliodbs(dot)com>, Darren Duncan <darren(at)darrenduncan(dot)net>, postgres hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: SQL command to edit postgresql.conf, with comments
Date: 2010-10-14 17:29:58
Message-ID: AANLkTi=Wd+QcLtA3g7UQz39w+jhVQuY5+P49GDeex1Bm@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-hackers
On Thu, Oct 14, 2010 at 9:50 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> The fact is that you cannot know the active value anyway without
> checking, because what you did with SET PERMANENT might be overridden
> in various session-local ways.  The proposal for hand-edited versus
> machine-edited files just adds one more layer of possible overrides
> to the existing half-dozen layers, all of which are widely considered
> features not bugs.  So I see no merit in your argument.

You know, this is a good point.  I was really hoping for a single
file, but maybe two files is not so bad as I think it is.  However, I
kind of dislike SET PERMANENT as a command name, partly because I
think it sounds more certain than it really is, and partly because
it's asymmetric with the other, similar GUC-setting commands, which
are:

ALTER ROLE name [ IN DATABASE database_name ] SET
configuration_parameter { TO | = } { value | DEFAULT }
ALTER DATABASE name SET configuration_parameter { TO | = } { value | DEFAULT }

Perhaps ALTER SYSTEM SET configuration_parameter { TO | = } { value |
DEFAULT } ?

A similar syntax exists in Oracle:

http://stanford.edu/dept/itss/docs/oracle/10g/server.101/b10759/statements_2013.htm#i2282157

From what I gather this works out to:

ALTER SYSTEM SCOPE = { MEMORY | SPFILE | BOTH } SET
configuration_paramater = value

(I don't think we can the SCOPE clause because I believe the only way
we have of propagating a GUC through the system is to have all the
backends reread the file.)

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

In response to

Responses

pgsql-hackers by date

Next:From: Bernd HelmleDate: 2010-10-14 17:36:39
Subject: Re: Re: starting to review the Extend NOT NULL representation to pg_constraint patch
Previous:From: Kevin GrittnerDate: 2010-10-14 17:25:13
Subject: Re: [JDBC] Support for JDBC setQueryTimeout, et al.

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group