Thomas Lockhart wrote:
> > 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
Feel free to change so that the envar must be leading. It is definitely easier
code with this restriction and definately faster.
If you want, I will make the change. If the restriction is desired, I can make
the code in database.c and my code common.
Jeff
