Обсуждение: Win32 sysconfig -> pg_service.conf
Folks, I'm trying to get pg_service.conf working on Windows so we can standardize on a way of doing things cross-platform, and noticed that pg_config.exe --configure 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? Cheers, D -- David Fetter <david@fetter.org> http://fetter.org/ phone: +1 415 235 3778 AIM: dfetter666 Skype: davidfetter Remember to vote!
David Fetter wrote: > Folks, > > I'm trying to get pg_service.conf working on Windows so we can > standardize on a way of doing things cross-platform, and noticed that > > pg_config.exe --configure > why are you using this flag? if you leave it off you will see everything. > 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? cheers andrew
On Wed, Mar 29, 2006 at 03:53:13PM -0500, Andrew Dunstan wrote: > David Fetter wrote: > >Folks, > > > >I'm trying to get pg_service.conf working on Windows so we can > >standardize on a way of doing things cross-platform, and noticed > >that > > > >pg_config.exe --configure > > why are you using this flag? if you leave it off you will see > everything. Per IRC discussion, there's no default set in the windows distribution. > >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. Cheers, D -- David Fetter <david@fetter.org> http://fetter.org/ phone: +1 415 235 3778 AIM: dfetter666 Skype: davidfetter Remember to vote!
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 anypath. 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? cheers andrew
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. +