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