[EMAIL PROTECTED] writes:
> Dumping from 7.2 using 7.3 gives:
> CREATE FUNCTION postgis_gist_sel (opaque, oid, opaque, integer) RETURNS double
>precision
> AS '/var/lib/pgsql7.2.1/lib/contrib/libpostgis.so.0.7', 'postgis_gist_sel'
> LANGUAGE "C";
It's fairly unlikely that the 7.2 version of postgis (or anything else
that deals in 'internal' datatypes) would work in 7.3 anyway, so I
cannot get excited about this. The best update procedure is probably
to load the 7.3 version into your new database before you restore ---
then the 7.2 definitions will fail (at least where they conflict) and
you'll be all set.
> It also highlights another problem: that the full path name of objects
> is used when dumping functions. Should this not be
> installation-relative, if it is in the install tree?
This is not pg_dump's fault, it is postgis' fault for not using $libdir
in the definition of the function. If you look at any of the standard
contrib modules, you'll find they use version-free paths like
CREATE FUNCTION int4key_in(cstring)
RETURNS int4key
AS '$libdir/btree_gist'
LANGUAGE 'c' WITH (isstrict);
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 3: 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
