Bug #826: opaque->internal translation required for 7.2 dumps
Philip Warner (pjw@rhyme.com.au) reports a bug with a severity of 2
The lower the number the more severe it is.
Short Description
opaque->internal translation required for 7.2 dumps
Long Description
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";
...
CREATE OPERATOR && (
PROCEDURE = geometry_overlap,
LEFTARG = geometry,
RIGHTARG = geometry,
COMMUTATOR = &&,
RESTRICT = postgis_gist_sel,
JOIN = positionjoinsel
);
Which results in the following error:
ERROR: OperatorDef: function postgis_gist_sel(internal, oid, internal, integer) does not exist
pg_restore: [archiver (db)] could not execute query: ERROR: OperatorDef: function postgis_gist_sel(internal, oid, internal, integer
) does not exist
This is similar to the problems we had earlier with opaque->internal conversions.
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?
Sample Code
No file was uploaded with this report
pgsql-bugs@postgresql.org 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