Andrew Dunstan wrote: > > > David Fetter wrote: > > >>>doesn't report anything by way of --sysconfdir, which in turn means > >>>that people have to do some fragile hackery in order even to see a > >>>pg_service.conf file. Can we put such a configuration directive > >>>into the binary builds? Is this known to work? > >>> > >>> > >>In any case, the default is $prefix/etc which is probably not what > >>you want anyway - why not set the PGSYSCONFDIR environment variable > >>to point to where you put the service file? > >> > >> > > > >Let's turn that question around. Why *shouldn't* there be a default > >built in? "No default" seems like a pretty poor fall-through. > > > > > > > > > > On further investigation, this appears to be an artifact of the > directory not existing, causing GetShortPathName to return an empty > string, as noted in this comment: > > * This can fail in 2 ways - if the path doesn't exist, or short names are > * disabled. In the first case, don't return any path. > > I think maybe we need a pg_config switch to allow us to fall back to > GetFullPathName, which does not fail if the target doesn't exist. After > all, it's cold comfort that libpq probably does the right thing if we > don't have any reasonable way of finding out what that is. > > In the case of Windows binary packages, the place that actually works is > apparently $bindir/../etc > > thoughts?
In looking at cleanup_path(), why don't we just return the original string if GetShortPathName() doesn't return anything? -- Bruce Momjian http://candle.pha.pa.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---------------------------(end of broadcast)--------------------------- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match