> I moved the discussion from General to Hackers, as I am getting into actual
> code changes now. I hope this is appropriate.
Yup.
> I'm not exactly sure which code you are referring to. I did see the
> following places where environment variables in paths are expanded:
...
> backend/utils/misc/database.c:
> This code is only applicable to finding the path to the database
> directory. It has a hardwired 'base' in the expanded pathname. Also only
> environment variables in the beginning of the path are supported.
This is the one I was thinking of. The "leading envar" is pretty
unambiguous; allowing them farther into the string will restrict paths
from having a dollar sign (not terribly important, but it is an obscure
restriction). Also, and probably more important, by requiring that the
envar be in the first position it is a simple one-byte comparison to see
if any expansion *may* need to be done. So the performance is not
affected at all if no environment variable is used.
> If y'all want the code, here are the diffs. The are from 7.0.2. I made,
> what I think, are the appropriate changes to the documentation. I do not
> have a way to build the documentation so I can't see how my changes actually
> look - I hope they are appropriately formatted.
Thanks. Shall we tweak it to support the same conventions as for the
other cases (leading envar only)? It will remove any possible objection
regarding efficiency, and it will conform to the other usages (btw, the
"hardwired 'base/' in the database.c example could/should be considered
a security feature since it requires a well-formed directory structure).
- Thomas
