Re: Win32 sysconfig -> pg_service.conf - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: Win32 sysconfig -> pg_service.conf
Date
Msg-id 200604212330.k3LNUAf00981@candle.pha.pa.us
Whole thread Raw
In response to Re: Win32 sysconfig -> pg_service.conf  (Andrew Dunstan <andrew@dunslane.net>)
List pgsql-hackers
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. +


pgsql-hackers by date:

Previous
From: Simon Riggs
Date:
Subject: Re: Further reduction of bufmgr lock contention
Next
From: Bruce Momjian
Date:
Subject: Re: proposal - plpgsql: execute using into