imagenesis@xxxxxxxxx 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. -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
