"Tom Lane" <[EMAIL PROTECTED]> writes: > Andrew Dunstan <[EMAIL PROTECTED]> writes: >> All this discussion seems to me to be going off into the clouds, where >> every objection is met with some still more elaborate scheme. I think we >> need to look at simple, incremental, and if possible backwards >> compatible changes. > > +1. Let me propose the simplest possible scheme, namely > > The SQL-exposed function knows how to find and replace the definition > of a variable (commented or otherwise) in the primary configuration > file. It does not chase INCLUDEs. If it doesn't find the target > variable anyplace in the primary file, it errors out.
I think there are a few problems with having the function edit the primary config file: 1) It requires parsing and dealing with arbitrary user data. There could be comments on the same line, the order or white-space might be important to the user, etc. 2) How would this interact with config files outside of the data directory? If you have multiple postgres clusters using the same config fie or if your config file is in read-only media (as /etc often is) or if you're a packager where editing user-maintained /etc files is a forbidden and an awful idea this all leads to problems. I think it's much cleaner to have a postgresql.conf.auto file in the data directory which has a limited syntax. No comments, no extra white-space, and no includes. The user is not expected to edit it, though he can. The functions edit it using simple algorithms which add and remove single lines. The default config file then includes this postgresql.conf.auto and the sysadmin can decide whether to keep or remove that include, change configuration options before or after the include, etc. Actually this is very similar to how a lot of other packages manage their automatically maintained data. Apache used to be done like this on Debian (now it's a bit more complex using a directory, but the same idea). Emacs's custom.el package can be set up in a similar way where custom.el edits a separate file which you include from your .emacs. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's Slony Replication support! ---------------------------(end of broadcast)--------------------------- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
