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 ---------------------------(end of broadcast)--------------------------- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq

"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 ---------------------------(end of broadcast)--------------------------- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to majordomo@postgresql.org so that your message can get through to the mailing list cleanly

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 ---------------------------(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