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 thatpg_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
thatpg_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 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?
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/../etcthoughts?
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. +
On Win32, patch applied to return path if GetShortPathName() fails (no
short name, path does not exist), rather than returning nothing.
Backpatch to 8.1.X.
---------------------------------------------------------------------------
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/../etcthoughts?
cheers
andrew
---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings
--
Bruce Momjian http://candle.pha.pa.us
EnterpriseDB http://www.enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
Attachments:
/rtmp/difftext/x-diffDownload+18-23
Bruce Momjian said:
On Win32, patch applied to return path if GetShortPathName() fails (no
short name, path does not exist), rather than returning nothing.
What made you choose this rather than GetFullPathName?
cheers
andrew
Import Notes
Resolved by subject fallback
Bruce Momjian <pgman@candle.pha.pa.us> writes:
On Win32, patch applied to return path if GetShortPathName() fails (no
short name, path does not exist), rather than returning nothing.
Hm, are you sure GetShortPathName will never modify the path before
failing? For instance, I'd be a bit worried about cases where it
successfully adjusts some components of the path before finding one that
doesn't exist.
regards, tom lane
Andrew Dunstan wrote:
Bruce Momjian said:
On Win32, patch applied to return path if GetShortPathName() fails (no
short name, path does not exist), rather than returning nothing.
What made you choose this rather than GetFullPathName?
Sure, we can do that. Does GetFullPathName() work if the path does not
exist? How is it different from the path we pass to it? Aren't all
those paths full already?
--
Bruce Momjian http://candle.pha.pa.us
EnterpriseDB http://www.enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
Tom Lane wrote:
Bruce Momjian <pgman@candle.pha.pa.us> writes:
On Win32, patch applied to return path if GetShortPathName() fails (no
short name, path does not exist), rather than returning nothing.Hm, are you sure GetShortPathName will never modify the path before
failing? For instance, I'd be a bit worried about cases where it
successfully adjusts some components of the path before finding one that
doesn't exist.
Good point. Would someone test that? Is GetFullPathName() the proper
direction?
--
Bruce Momjian http://candle.pha.pa.us
EnterpriseDB http://www.enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
Bruce Momjian wrote:
Andrew Dunstan wrote:
Bruce Momjian said:
On Win32, patch applied to return path if GetShortPathName() fails (no
short name, path does not exist), rather than returning nothing.
What made you choose this rather than GetFullPathName?
Sure, we can do that. Does GetFullPathName() work if the path does not
exist?
yes. see
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/fileio/fs/getfullpathname.asp
How is it different from the path we pass to it? Aren't all
those paths full already?
If they are then it probably doesn't matter.
cheers
andrew
Andrew Dunstan wrote:
What made you choose this rather than GetFullPathName?
Sure, we can do that. Does GetFullPathName() work if the path does not
exist?yes. see
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/fileio/fs/getfullpathname.aspHow is it different from the path we pass to it? Aren't all
those paths full already?If they are then it probably doesn't matter.
The reason I don't want to use GetFullPathName() is because on Unix, we
just return the specified path, not the full path, so I don't want to do
something different on Win32 unless we have to. There is good reason to
get the short path on Win32, if we can, but no logic to returning the
full path only on Win32, if that is not what was specified by configure.
--
Bruce Momjian http://candle.pha.pa.us
EnterpriseDB http://www.enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
Bruce Momjian wrote:
How is it different from the path we pass to it? Aren't all
those paths full already?If they are then it probably doesn't matter.
The reason I don't want to use GetFullPathName() is because on Unix, we
just return the specified path, not the full path, so I don't want to do
something different on Win32 unless we have to. There is good reason to
get the short path on Win32, if we can, but no logic to returning the
full path only on Win32, if that is not what was specified by configure.
OK
cheers
andrew