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

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

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