Re: Can we avoid chdir'ing in resolve_symlinks() ?

Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
> I think the discussion here is a bit tangential to the original topic.

Indeed, because I just wanted to reimplement *how* we resolve the
executable path to absolute, not question whether we should do it at all.

> The point you make is reasonable, but it seems a bit more likely that in
> the case Peter cites the symlink is one level higher in the tree, in
> which case there's probably little value in resolving the symlink. Maybe
> we could compromise and check if a path exists and only resolve symlinks
> if it does not?

It's non-negotiable that we apply realpath() or a handmade equivalent
if the path we find to the executable turns out to be relative, ie
you did "../../postgres/bin/psql" or the equivalent. In the case of
the server, we *will* chdir to someplace else, rendering the original
path useless. psql might chdir in response to a user command, so it
likewise had better resolve the installation location while it can.

We could maybe skip realpath() if we find what appears to be an
absolute path to the executable. However, I think that fails in
too many situations. As an example, if I do
ln -s /path/to/psql ~/bin
and then invoke psql using that symlink, we're not going to be
able to find any of the installation's supporting files unless
we resolve the symlink. The executable path we'd deduce after
examining PATH is /home/tgl/bin/psql, which is plenty absolute,
but it doesn't help us find the rest of the PG installation.
That case works today, and I think a lot of people will be
sad if we break it.

I'm not familiar with how homebrew sets up the installation
layout, but I'm suspicious that the situation Peter refers to
has a similar problem, only with a symlink for the bin directory
not the individual executable.

I think the only potentially-workable alternative design is
to forget about relocatable installations and insist that the
supporting files be found at the installation path designated
at configure time. But, again, that seems likely to break a
lot of setups that work today. And I've still not heard a
positive reason why we should change it.

regards, tom lane