Re: Use environment variables in postgresql.conf

Hi,

On Sat, Nov 30, 2013 at 08:43:53PM -0500, imagenesis(at)gmail(dot)com 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(at)crankycanuck(dot)ca