imagenesis@gmail.com wrote
> The questions are:
>
> 1. Has var expansion in configuration files been contemplated?
> 2. Why not do it?
1. Probably
2. More important things to focus on; distros/installers all have their own
idea of what is "best" so the decisions have been left to these OS-specific
entities.
> Reasons why it's perhaps useful to change the presumed workflow:
>
> 1. It's perhaps inconvenient
> 2. Variables are a fundamental concept for configuration
> 3. Moving configuration to os specific scripts defies the DRY (don't
> repeat
> yourself) paradigm
1. Not enough for someone to propose a working patch apparently
2. OK
3. Possibly...and see my response to #2 above
> 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.
> 2. Variable expansion should be done in postgresql specific configuration
> files.
You seem to only care about Linux...and this workflow seem woefully
incomplete. If you have something specific in mind please share.
> On the other hand:
> 1. One could just generate the conf files
> 2. Assign env vars to absolute paths/symbolic links
1. Yes, this seems to be a useful approach.
2. Hey, if it works for you.
> 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. Please evaluate the value of workflows
> facilitated
> by said modifications. Using the OS specific start up scripts for
> configuration of contexts they are intended to initiate is fundamentally
> incorrect.
To be fair the current implementation has probably been around for the past
10 years - well before current DevOps thinking, Puppet/Chef, etc... came
around. It seems to work for the vast majority of cases, across numerous
OSs, and different distros have indeed done some tweaking to make things
easier for their platforms.
PostgreSQL itself can provide a more flexible and manageable installation
platform if the need can be sold to the current group of -hackers or if
someone with enough motivation comes in with a well-designed proposal.
Changing core in this way, though, might take 2-3 years. Or that someone
takes what is currently in place and creates a friendly wrapper on top of it
- just like distros do currently - and releases/uses it whenever it is
ready.
So, in summary, it is better to contribute than to conform.
David J.
--
View this message in context:
http://postgresql.1045698.n5.nabble.com/Use-environment-variables-in-postgresql-conf-tp5781027p5781037.html
Sent from the PostgreSQL - general mailing list archive at Nabble.com.
