Hi, On Sat, Nov 30, 2013 at 08:43:53PM -0500, imagenesis@xxxxxxxxx wrote: > The questions are: > > 1. Has var expansion in configuration files been contemplated? > 2. Why not do it? Several years ago on the -hackers list (I couldn't say how many, but I was still supervising the database operations at Afilias so it's at least pre-2006) there was a big fight about environment variables and how to handle them. Feelings ran high, and I seem to recall that one of the participants involved basically pulled back from Postgres work after that because of his frustration. I'd suggest trolling the -hackers archives for "environment variable" during the period (say) from 2003 through 2005. But in answer to (2), basically the reason is that if you have multiple ways of setting a value, it is extremely hard for an operator to figure out what the setting of a running process _actually_ is. Environment variables are especially bad, because they're hard to retrieve from a running session in an interoperable way and they're impossible to inspect if the calling shell is gone. If you say, "But I choose to take that risk," you forget that the project incurs support costs whenever such inconsistencies pop out. > Reasons why it's perhaps useful to change the presumed workflow: > > 1. It's perhaps inconvenient I don't see why. If you're going to write a shell script anyway to set these things, I don't see what the big deal is. > 2. Variables are a fundamental concept for configuration > 3. Moving configuration to os specific scripts defies the DRY (don't repeat > yourself) paradigm You can use include files against a base postgres.conf file to avoid repeating yourself. You're certainly going to have to repeat at least the setting of some variables. > Proposed workflow: > 1. Environment initialization, meaning the declaration of environment > variables (in the sense that "env -i" is probably spawned in the OS > specific scripts and is thus quite empty) for "pg_ctl" should be done in a > postgresql specific shell file. Why in the world do you want to involve the shell in an already-complex configuration situation? Particularly since Postgres also runs on Windows? And that the "standard" Bourne shell is either no standard at all, or else sufficiently limited for interoperation that the paradigm effectively becomes "write once, test everywhere"? What you are really saying is, "I have this idea to do something I can already do, only using a different work flow, so someone else should do the development work to support that." I guess if you want this badly enough you could propose the feature over on -hackers. I think it'd be a crazy feature, though. > Thanks for your reply Andrew, however I do not necessarily wish to conform > to arbitrary expectations forced by the current implementation if it is > inconvenient/incomplete. All engineering is a trade-off. In this case, the program is designed with a different mechanism to achieve the same end. It is a bad idea -- because it's a dangerous foot-gun -- to implement a different way to achieve the same ends: it increases code complexity and dramatically increases the risk that one part of the code will be altered without correctly altering the other part. What is inconvenient for you incereases the reliability of Postgres, and I humbly suggest that your evaluation of convenience in this case is anyway incomplete. Best, A -- Andrew Sullivan ajs@xxxxxxxxxxxxxxx -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
