Re: [HACKERS] Locating sharedir in PostgreSQL on Windows
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/ ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Locating sharedir in PostgreSQL on Windows
Peter Eisentraut [EMAIL PROTECTED] 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 ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Locating sharedir in PostgreSQL on Windows
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 ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
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? -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Locating sharedir in PostgreSQL on Windows
Tom Lane wrote: Peter Eisentraut [EMAIL PROTECTED] 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/ ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Locating sharedir in PostgreSQL on Windows
--- Original Message --- From: Peter Eisentraut [EMAIL PROTECTED] To: Dave Page [EMAIL PROTECTED] 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 simplifies version upgrades if the new installation is at a different location. The actual directory that $libdir stands for can be found out with the command pg_config --pkglibdir. == That seems to have been there since at least 7.2. /D ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Locating sharedir in PostgreSQL on Windows
Dave Page [EMAIL PROTECTED] writes: From: Peter Eisentraut [EMAIL PROTECTED] 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 simplifies version upgrades if the new installation is at a different location. The actual directory that $libdir stands for can 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 ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Locating sharedir in PostgreSQL on Windows
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 ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Locating sharedir in PostgreSQL on Windows
--- Original Message --- From: Tom Lane [EMAIL PROTECTED] To: Dave Page [EMAIL PROTECTED] 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 ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] Locating sharedir in PostgreSQL on Windows
Dave Page [EMAIL PROTECTED] 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 ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Locating sharedir in PostgreSQL on Windows
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 ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Locating sharedir in PostgreSQL on Windows
--- Original Message --- From: Tom Lane [EMAIL PROTECTED] To: Dave Page [EMAIL PROTECTED] Sent: 26/11/07, 22:30:17 Subject: Re: [HACKERS] Locating sharedir in PostgreSQL on Windows Dave Page [EMAIL PROTECTED] 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.sql etc. rather than config files. But, I see he's found his bug now anyway. /D ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Locating sharedir in PostgreSQL on Windows
Mark Cave-Ayland [EMAIL PROTECTED] 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 ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Locating sharedir in PostgreSQL on Windows
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/ ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
