Andrew Dunstan <and...@dunslane.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