Bruce Momjian wrote:
> > However, it misses the case with for example E:foo, which is a perfectly
> > valid path on windows. Which isn't absolute *or* relative - it's relative
> > to the current directory on the E: drive. Which will be the same as the
> > current directory for the process *if* the process current directory is
> > on drive E:. In other cases, it's a different directory.
> 
> I would argue that E:foo is always relative (which matches
> is_absolute_path()).  If E: is the current drive of the process, it is
> relative, and if the current drive is not E:, it is relative to the last
> current drive on E: for that process, or the top level if there was no
> current drive.  (Tested on XP.)
> 
> There seem to be three states:
> 
> 	1. absolute - already tested by is_absolute_path()
> 	2. relative to the current directory (current drive)
> 	3. relative on a different drive
> 
> We could probably develop code to test all three, but keep in mind that
> the path itself can't distinguish between 2 and 3, and while you can
> test the current drive, if the current drive changes, a 2 could become a
> 3, and via versa.

I have reviewed is_absolute_path() and have implemented
path_is_relative_and_below_cwd() to cleanly handle cases like 'E:abc' on
Win32;  patch attached.

-- 
  Bruce Momjian  <bruce(at)momjian(dot)us>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

  + It's impossible for everything to be true. +

In response to

• Re: is_absolute_path incorrect on Windows at 2010-06-01 00:22:47 from Bruce Momjian

Responses

• Re: is_absolute_path incorrect on Windows at 2011-02-03 17:26:00 from Tom Lane

pgsql-hackers by date

Next:	From: David E. Wheeler	Date: 2011-02-03 16:52:50
	Subject: Re: arrays as pl/perl input arguments [PATCH]
Previous:	From: Mladen Gogala	Date: 2011-02-03 16:38:14
	Subject: Re: [HACKERS] Slow count(*) again...