Re: Bug in canonicalize_path()

I wrote:
> Uh, that hardly meets the API contract that I mentioned. I think
> we really have to throw an error if the path tries to ".." above
> the starting point.

After rereading all the callers of canonicalize_path, I've concluded
that none of them actually depend on not having a terminating ".."
as I thought. There is a risk factor, which is that a lot of places
blindly trim the last component of a path --- but AFAICS, this is only
done with paths that are known to represent the name of a program,
so the last component wouldn't be ".." anyway.

So your last version of the patch seems like the way to go. I'll
apply it along with changing path.c to support the parent-directory
test better.

regards, tom lane