Thread: Locating sharedir in PostgreSQL on Windows
Hi everyone, I'm working on a piece of code for PostGIS to allow the loading of projection configuration files from the share/postgresql directory, but I can't find a way of getting this to work under Win32. AIUI the way to do this would be to use a combination of my_exec_path and get_share_path in order to find the directory, but MingW refuses to find the my_exec_path variable during linking. Unfortunately I suspect that this because my_exec_path is not declared as DLLIMPORT in backend/utils/init/globals.c :( I really need to find a solution to this that can work all the way back to PostgreSQL 8.0 - can anyone think of any better ideas? Many thanks, Mark. -- ILande - Open Source Consultancy http://www.ilande.co.uk
Am Montag, 26. November 2007 schrieb Mark Cave-Ayland: > I'm working on a piece of code for PostGIS to allow the loading of > projection configuration files from the share/postgresql directory, but The share directory is the wrong place for configuration files anyway. And moreover, non-PostgreSQL packages have no business putting files into PostgreSQL's private directories. -- Peter Eisentraut http://developer.postgresql.org/~petere/
Peter Eisentraut <peter_e@gmx.net> writes:
> Am Montag, 26. November 2007 schrieb Mark Cave-Ayland:
>> I'm working on a piece of code for PostGIS to allow the loading of
>> projection configuration files from the share/postgresql directory, but
> The share directory is the wrong place for configuration files anyway. And
> moreover, non-PostgreSQL packages have no business putting files into
> PostgreSQL's private directories.
That doesn't seem logical to me. We expect tsearch configuration files
to be put into $sharedir/tsearch_data, so why shouldn't PostGIS use a
similar approach to dealing with external configuration data?
I'm not sure why Mark's having a problem accessing my_exec_path ---
it *is* declared DLLIMPORT in miscadmin.h (which is where it counts,
AIUI) clear back to 8.0.
regards, tom lane
Peter Eisentraut wrote: > Am Montag, 26. November 2007 schrieb Mark Cave-Ayland: >> I'm working on a piece of code for PostGIS to allow the loading of >> projection configuration files from the share/postgresql directory, but > > The share directory is the wrong place for configuration files anyway. And > moreover, non-PostgreSQL packages have no business putting files into > PostgreSQL's private directories. > How does that work with the stuff that goes into directories relative to $libdir (per documented recommendations), without creating easy-to-break paths like $libdir/../../MyAddon/8.3/MyAddon.dll? Regards, Dave
Dave Page wrote: > How does that work with the stuff that goes into directories relative to > $libdir (per documented recommendations), without creating easy-to-break > paths like $libdir/../../MyAddon/8.3/MyAddon.dll? Which documented recommendation do you speak of? -- Peter Eisentraut http://developer.postgresql.org/~petere/
Tom Lane wrote: > Peter Eisentraut <peter_e@gmx.net> writes: > > Am Montag, 26. November 2007 schrieb Mark Cave-Ayland: > >> I'm working on a piece of code for PostGIS to allow the loading of > >> projection configuration files from the share/postgresql directory, but > > > > The share directory is the wrong place for configuration files anyway. > > And moreover, non-PostgreSQL packages have no business putting files into > > PostgreSQL's private directories. > > That doesn't seem logical to me. We expect tsearch configuration files > to be put into $sharedir/tsearch_data, so why shouldn't PostGIS use a > similar approach to dealing with external configuration data? Well, PostGIS is not PostgreSQL. And those files are not really configuration files, in the sense that the user configures them, but data files (or else they are in the wrong place). -- Peter Eisentraut http://developer.postgresql.org/~petere/
> ------- Original Message ------- > From: Peter Eisentraut <peter_e@gmx.net> > To: Dave Page <dpage@postgresql.org> > Sent: 26/11/07, 20:14:25 > Subject: Re: [HACKERS] Locating sharedir in PostgreSQL on Windows > > Dave Page wrote: > > How does that work with the stuff that goes into directories relative to > > $libdir (per documented recommendations), without creating easy-to-break > > paths like $libdir/../../MyAddon/8.3/MyAddon.dll? > > Which documented recommendation do you speak of? > http://www.postgresql.org/docs/8.3/static/xfunc-c.html states: ========== It is recommended to locate shared libraries either relative to $libdir or through the dynamic library path. This simplifiesversion upgrades if the new installation is at a different location. The actual directory that $libdir stands forcan be found out with the command pg_config --pkglibdir. ========== That seems to have been there since at least 7.2. /D
"Dave Page" <dpage@postgresql.org> writes: > From: Peter Eisentraut <peter_e@gmx.net> >> Which documented recommendation do you speak of? > http://www.postgresql.org/docs/8.3/static/xfunc-c.html states: > It is recommended to locate shared libraries either relative to $libdir or through the dynamic library path. This simplifiesversion upgrades if the new installation is at a different location. The actual directory that $libdir stands forcan be found out with the command pg_config --pkglibdir. I believe that that is talking specifically about shared libraries (or DLLs in Windows-speak), and not about configuration or data files. In particular, nothing under libdir would be a candidate to go under sharedir, nor vice versa, since the former is supposed to hold architecture-dependent files and the latter architecture-independent files. Mark hasn't been very clear about whether he wants to store static data files or installation-changeable configuration info, so it's not clear to me whether Peter's objection to using sharedir is appropriate or not. But unless the files are architecture-sensitive (which they might be!), libdir doesn't sound right in either case. regards, tom lane
On Mon, 2007-11-26 at 11:55 -0500, Tom Lane wrote: > I'm not sure why Mark's having a problem accessing my_exec_path --- > it *is* declared DLLIMPORT in miscadmin.h (which is where it counts, > AIUI) clear back to 8.0. Bah, I think that is the source of the problem. Having grepped the source for my_exec_path, I found the reference in globals.c and hence the code worked on Linux (my main development environment) with a simple extern declaration which was what was confusing me. Adding the #include "miscadmin.h" solves this problem and I can now access the variable on Windows aswell, so I put this down to "user error" - thanks for the advice Tom. Many thanks, Mark. -- ILande - Open Source Consultancy http://www.ilande.co.uk
> ------- Original Message ------- > From: Tom Lane <tgl@sss.pgh.pa.us> > To: "Dave Page" <dpage@postgresql.org> > Sent: 26/11/07, 22:02:09 > Subject: Re: [HACKERS] Locating sharedir in PostgreSQL on Windows > > > I believe that that is talking specifically about shared libraries (or > DLLs in Windows-speak), and not about configuration or data files. > In particular, nothing under libdir would be a candidate to go under > sharedir, nor vice versa, since the former is supposed to hold > architecture-dependent files and the latter architecture-independent > files. Yes, I know. Peter seemed to be saying that nothing except postgres itself should be in *any* of the installation directories(he called them 'private' directories by which I imagine he meant an install in /usr/local/pgsql/ vs /usr/local,or more specifically the case when $libdir is something like /usr/lib/postgresql) /D
"Dave Page" <dpage@postgresql.org> writes:
> Yes, I know. Peter seemed to be saying that nothing except postgres
> itself should be in *any* of the installation directories
Yeah, that's what I think he said too, but it strikes me as a completely
bogus policy --- what about contrib modules or stuff from pgfoundry
or any random user-written module that was built with PGXS? All that
stuff happily drops files under $libdir and $sharedir, and I see no good
argument why it shouldn't.
There is fair room for argument about whether $sharedir is the
appropriate place for installation-specific config files though.
Those should probably live in the same place as postgresql.conf
and friends, ie, typically but not necessarily $PGDATA. It doesn't
look like SelectConfigFiles() saves the config directory name anyplace
where an add-on module could get at it. We could perhaps fix that for
8.3, but it won't help Mark if he insists on a backwards-compatible
solution. I suppose he could copy ConfigFileName and strip the last
component from it?
regards, tom lane
On Mon, 2007-11-26 at 17:02 -0500, Tom Lane wrote: > I believe that that is talking specifically about shared libraries (or > DLLs in Windows-speak), and not about configuration or data files. > In particular, nothing under libdir would be a candidate to go under > sharedir, nor vice versa, since the former is supposed to hold > architecture-dependent files and the latter architecture-independent > files. > > Mark hasn't been very clear about whether he wants to store static data > files or installation-changeable configuration info, so it's not clear > to me whether Peter's objection to using sharedir is appropriate or not. > But unless the files are architecture-sensitive (which they might be!), > libdir doesn't sound right in either case. Okay, I'll try and expand on this a bit. In order to convert coordinates between different coordinate systems, PostGIS uses the external PROJ.4 library. Now in order to support a certain category of conversion, PROJ.4 requires access to a set of library grid reference files which are effectively "compiled" from source files into a set of data files as part of the build process. The path to this directory of files is then built into the DLL at compile time, although it can be overriden with an API call. Under Linux, this is fairly easy as the files are normally installed somewhere under /usr/share/proj, and hence the directory exists at both compile-time and run-time. Windows is trickier because drive letters and mappings can change - the default of C:\PROJ\NAD may or may not exist, or can change depending upon the current drive configuration. I can also see issues arising if the PostgreSQL installation is moved from the C:\ drive to another. Hence my idea was to create a directory under $sharedir such as $sharedir/postgresql/contrib/postgis/nad and install the files there. Then regardless of the location of the PostgreSQL installation or the current drive setup, I can use get_share_path() with the PROJ.4 API to set the new library path the first time the function is called, and everything will just work. I can see Peter's argument about not putting files directly in $sharedir, but I feel the usage suggested above falls under a similar use case to the tsearch2 data files (which is mostly where I looked for inspiration). Hopefully this will help make things a bit clearer - please let me know if any more information is needed. Many thanks, Mark. -- ILande - Open Source Consultancy http://www.ilande.co.uk
> ------- Original Message ------- > From: Tom Lane <tgl@sss.pgh.pa.us> > To: "Dave Page" <dpage@postgresql.org> > Sent: 26/11/07, 22:30:17 > Subject: Re: [HACKERS] Locating sharedir in PostgreSQL on Windows > > "Dave Page" <dpage@postgresql.org> writes: > > Yes, I know. Peter seemed to be saying that nothing except postgres > > itself should be in *any* of the installation directories > > Yeah, that's what I think he said too, but it strikes me as a completely > bogus policy --- what about contrib modules or stuff from pgfoundry > or any random user-written module that was built with PGXS? All that > stuff happily drops files under $libdir and $sharedir, and I see no good > argument why it shouldn't. Yup, exactly. > There is fair room for argument about whether $sharedir is the > appropriate place for installation-specific config files though. > Those should probably live in the same place as postgresql.conf > and friends, ie, typically but not necessarily $PGDATA. It doesn't > look like SelectConfigFiles() saves the config directory name anyplace > where an add-on module could get at it. We could perhaps fix that for > 8.3, but it won't help Mark if he insists on a backwards-compatible > solution. I suppose he could copy ConfigFileName and strip the last > component from it? Wouldn't be difficult, but I suspect Mark is probably using the path for the PostGIS SQL scripts lwgeom.sql, spatial_ref_sys.sqletc. rather than config files. But, I see he's found his bug now anyway. /D
Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> writes:
> Okay, I'll try and expand on this a bit. In order to convert coordinates
> between different coordinate systems, PostGIS uses the external PROJ.4
> library. Now in order to support a certain category of conversion,
> PROJ.4 requires access to a set of library grid reference files which
> are effectively "compiled" from source files into a set of data files as
> part of the build process. The path to this directory of files is then
> built into the DLL at compile time, although it can be overriden with an
> API call.
> Under Linux, this is fairly easy as the files are normally installed
> somewhere under /usr/share/proj, and hence the directory exists at both
> compile-time and run-time.
OK, if the files are normally under /usr/share then it's presumably
kosher to put them under our $sharedir. I guess the only question is
whether you are worried about having two copies in a machine where
PROJ.4 is also installed natively.
regards, tom lane
Tom Lane wrote: > Yeah, that's what I think he said too, but it strikes me as a completely > bogus policy --- what about contrib modules or stuff from pgfoundry > or any random user-written module that was built with PGXS? All that > stuff happily drops files under $libdir and $sharedir, and I see no good > argument why it shouldn't. We have an implicit policy for those two specific cases, which are OK with me. I guess it's better to look at specific use cases instead of interpreting other people's abstract directory descriptions. ;-) -- Peter Eisentraut http://developer.postgresql.org/~petere/