Re: 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(at)fetter(dot)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(at)fetter(dot)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/../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. +

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/../etc
>
> thoughts?
>
> 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. +

Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)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(at)candle(dot)pha(dot)pa(dot)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. +