dynamic_library_path on Win32

Thomas Hallgren wrote:

I'm using CVS HEAD in a windows environment. I'm trying to start the
postmaster using "postmaster -c dynamic_library_path=C:/foo/bar". It starts
just fine, then, when I ask it to load a module, an error is generating
stating:

ERROR: component in parameter "dynamic_library_path" is not an absolute path

I added a trace to find out what it thinks the path is. It prints "C".
Obviously it treats ':' as a path separator somewhere. Is that the intended
behavior on win32?

You've found a bug. Clearly we need to adjust the parsing of
dynamic_library_path and probably preload_libraries for Win32.

cheers

andrew

"Thomas Hallgren" <thhal@mailblocks.com> writes:

I'm using CVS HEAD in a windows environment. I'm trying to start the
postmaster using "postmaster -c dynamic_library_path=C:/foo/bar". It starts
just fine, then, when I ask it to load a module, an error is generating
stating:

ERROR: component in parameter "dynamic_library_path" is not an absolute path

I added a trace to find out what it thinks the path is. It prints "C".
Obviously it treats ':' as a path separator somewhere.

Yeah. dynamic_library_path follows the universal Unix convention that
search path components are separated by ':'. Is there any equivalent
convention in Windows?

regards, tom lane

Yes, on windows, you use a semicolon as path separator.

regards,

- thomas

----- Original Message -----
From: "Tom Lane" <tgl@sss.pgh.pa.us>
To: "Thomas Hallgren" <thhal@mailblocks.com>
Cc: <pgsql-hackers@postgresql.org>
Sent: Saturday, May 29, 2004 17:20
Subject: Re: [HACKERS] dynamic_library_path on Win32

"Thomas Hallgren" <thhal@mailblocks.com> writes:

I'm using CVS HEAD in a windows environment. I'm trying to start the
postmaster using "postmaster -c dynamic_library_path=C:/foo/bar". It

starts

just fine, then, when I ask it to load a module, an error is generating
stating:

ERROR: component in parameter "dynamic_library_path" is not an absolute

path

I'm using CVS HEAD in a windows environment. I'm trying to start the
postmaster using "postmaster -c

dynamic_library_path=C:/foo/bar". It starts

just fine, then, when I ask it to load a module, an error is

generating

stating:

ERROR: component in parameter "dynamic_library_path" is not

an absolute path

I added a trace to find out what it thinks the path is. It

prints "C".

Obviously it treats ':' as a path separator somewhere.

Yeah. dynamic_library_path follows the universal Unix convention that
search path components are separated by ':'. Is there any equivalent
convention in Windows?

';' is what's used in PATH, and several other such places.

//Magnus

Tom Lane wrote:

"Thomas Hallgren" <thhal@mailblocks.com> writes:

I'm using CVS HEAD in a windows environment. I'm trying to start the
postmaster using "postmaster -c dynamic_library_path=C:/foo/bar". It starts
just fine, then, when I ask it to load a module, an error is generating
stating:

ERROR: component in parameter "dynamic_library_path" is not an absolute path

I added a trace to find out what it thinks the path is. It prints "C".
Obviously it treats ':' as a path separator somewhere.

Yeah. dynamic_library_path follows the universal Unix convention that
search path components are separated by ':'. Is there any equivalent
convention in Windows?

src/port/exec.c has this:

#ifdef WIN32
#define PATHSEP ';'
#else
#define PATHSEP ':'
#endif

It should probably move to c.h.

cheers

andrew

Andrew Dunstan <andrew@dunslane.net> writes:

You've found a bug. Clearly we need to adjust the parsing of
dynamic_library_path and probably preload_libraries for Win32.

Yup. Using PATHSEP sounded reasonable to me. Any volunteer to fix
this? (Don't forget to patch the docs for these variables, too.)

regards, tom lane

I can do it but will be a few days until I get to it.

---------------------------------------------------------------------------

Tom Lane wrote:

Andrew Dunstan <andrew@dunslane.net> writes:

You've found a bug. Clearly we need to adjust the parsing of
dynamic_library_path and probably preload_libraries for Win32.

Yup. Using PATHSEP sounded reasonable to me. Any volunteer to fix
this? (Don't forget to patch the docs for these variables, too.)

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Attached is a patch that takes care of the PATHSEP issue. I made a more
extensive change then what was suggested. I found the file path.c that
contained a lot of "Unix/Windows" agnostic functions so I added a function
there instead and removed the PATHSEP declaration in exec.c altogether. All
to keep things from scattering all over the code.

I also took the liberty of changing the name of the functions
"first_path_sep" and "last_path_sep". Where I come from (and I'm apparently
not alone given the former macro name PATHSEP), they should be called
"first_dir_sep" and "last_dir_sep". The new function I introduced, that
actually finds path separators, is now the "first_path_sep". The patch
contains changes on all affected places of course.

I also changed the documentation on dynamic_library_path to reflect the
chagnes.

Kind regards,

Thomas Hallgren

"Bruce Momjian" <pgman@candle.pha.pa.us> wrote in message
news:200405300307.i4U37sE17714@candle.pha.pa.us...

I can do it but will be a few days until I get to it.

--------------------------------------------------------------------------

-

Tom Lane wrote:

Andrew Dunstan <andrew@dunslane.net> writes:

You've found a bug. Clearly we need to adjust the parsing of
dynamic_library_path and probably preload_libraries for Win32.

Yup. Using PATHSEP sounded reasonable to me. Any volunteer to fix
this? (Don't forget to patch the docs for these variables, too.)

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster

-- 
Bruce Momjian                        |  http://candle.pha.pa.us
pgman@candle.pha.pa.us               |  (610) 359-1001
+  If your life is a hard drive,     |  13 Roberts Road
+  Christ can be your backup.        |  Newtown Square, Pennsylvania

19073

Your patch has been added to the PostgreSQL unapplied patches list at:

http://momjian.postgresql.org/cgi-bin/pgpatches

I will try to apply it within the next 48 hours.

I will try to clean up the path/dir confusion too.

---------------------------------------------------------------------------

Thomas Hallgren wrote:

Attached is a patch that takes care of the PATHSEP issue. I made a more
extensive change then what was suggested. I found the file path.c that
contained a lot of "Unix/Windows" agnostic functions so I added a function
there instead and removed the PATHSEP declaration in exec.c altogether. All
to keep things from scattering all over the code.

I also took the liberty of changing the name of the functions
"first_path_sep" and "last_path_sep". Where I come from (and I'm apparently
not alone given the former macro name PATHSEP), they should be called
"first_dir_sep" and "last_dir_sep". The new function I introduced, that
actually finds path separators, is now the "first_path_sep". The patch
contains changes on all affected places of course.

I also changed the documentation on dynamic_library_path to reflect the
chagnes.

Kind regards,

Thomas Hallgren

"Bruce Momjian" <pgman@candle.pha.pa.us> wrote in message
news:200405300307.i4U37sE17714@candle.pha.pa.us...

I can do it but will be a few days until I get to it.

--------------------------------------------------------------------------

-

Tom Lane wrote:

Andrew Dunstan <andrew@dunslane.net> writes:

You've found a bug. Clearly we need to adjust the parsing of
dynamic_library_path and probably preload_libraries for Win32.

Yup. Using PATHSEP sounded reasonable to me. Any volunteer to fix
this? (Don't forget to patch the docs for these variables, too.)

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster

-- 
Bruce Momjian                        |  http://candle.pha.pa.us
pgman@candle.pha.pa.us               |  (610) 359-1001
+  If your life is a hard drive,     |  13 Roberts Road
+  Christ can be your backup.        |  Newtown Square, Pennsylvania

19073

---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

http://archives.postgresql.org

[ Attachment, skipping... ]

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073