On Thu, Oct 14, 2010 at 9:50 AM, Tom Lane <t...@sss.pgh.pa.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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
