Re: Win32 sysconfig -> pg_service.conf
От | Bruce Momjian |
---|---|
Тема | Re: Win32 sysconfig -> pg_service.conf |
Дата | |
Msg-id | 200604212330.k3LNUAf00981@candle.pha.pa.us обсуждение исходный текст |
Ответ на | Re: Win32 sysconfig -> pg_service.conf (Andrew Dunstan <andrew@dunslane.net>) |
Список | 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 по дате отправления: