Обсуждение: 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 beinstallation-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