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. +