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