Re: BUG #4860: Indexes gone after restore - Mailing list pgsql-bugs

From Obe, Regina
Subject Re: BUG #4860: Indexes gone after restore
Date
Msg-id 53F9CF533E1AA14EA1F8C5C08ABC08D204D7F38D@ZDND.DND.boston.cob
Whole thread Raw
In response to BUG #4860: Indexes gone after restore  ("Regina" <robe.dnd@cityofboston.gov>)
Responses Re: BUG #4860: Indexes gone after restore
List pgsql-bugs
> Hum.  So the immediate problem is that st_transform() is failing to=0D
> schema-qualify its reference to spatial_ref_sys.  Think you need to=0D
> be filing that one against PostGIS, not us.=0D
=0D
=0D
Yah was sort of thinking that. =0D
=0D
Though what about this -- isn't this case a bit more common=0D
=0D
http://postgis.refractions.net/pipermail/postgis-users/2008-September/02139=
3.html=0D
=0D
If you have an index on a function that calls another function where the fu=
nction being called does not have the namespace specifically prefixed.=0D
=0D
In his example he had an index on ST_GeometryType (which calls the older fu=
nction GeometryType both residing in the public schema)=0D
=0D
So here is a more trivial example:=0D
=0D
using your original=0D
=0D
CREATE OR REPLACE FUNCTION foo(integer)=0D
  RETURNS integer AS=0D
'select $1+1'=0D
  LANGUAGE 'sql' IMMUTABLE;=0D
=0D
 CREATE OR REPLACE FUNCTION foo2(integer)=0D
        RETURNS integer As=0D
        $$SELECT foo($1)$$=0D
        LANGUAGE 'sql' IMMUTABLE;=0D
=0D
CREATE SCHEMA s1;=0D
create table s1.t1 (f1 int);=0D
create index i1 on s1.t1 (foo2(f1));=0D
=0D
Try to back that up and then restore it.=0D
=0D
error=0D
pg_restore: [archiver (db)] Error from TOC entry 1769; 0 38023 TABLE DATA t=
1 pos=0D
tgres=0D
pg_restore: [archiver (db)] COPY failed: ERROR:  function foo(integer) does=
 not=0D
exist=0D
LINE 1: SELECT foo($1)=0D
               ^=0D
HINT:  No function matches the given name and argument types. You might nee=
d to=0D
add explicit type casts.=0D
QUERY:  SELECT foo($1)=0D
CONTEXT:  SQL function "foo2" during inlining=0D
pg_restore: [archiver (db)] Error from TOC entry 1768; 1259 38029 INDEX i1 =
postg=0D
res=0D
pg_restore: [archiver (db)] could not execute query: ERROR:  relation "i1" =
alrea=0D
dy exists=0D
    Command was: CREATE INDEX i1 ON t1 USING btree (public.foo2(f1));=0D
WARNING: errors ignored on restore: 32=0D
=0D
Or do people not do this? I tend to a lot.=0D
=0D
=0D
=0D
=0D
=0D
=0D
-----------------------------------------=0D
The substance of this message, including any attachments, may be
confidential, legally privileged and/or exempt from disclosure
pursuant to Massachusetts law. It is intended=0D
solely for the addressee. If you received this in error, please
contact the sender and delete the material from any computer.=

pgsql-bugs by date:

Previous
From: Tom Lane
Date:
Subject: Re: BUG #4860: Indexes gone after restore
Next
From: Tom Lane
Date:
Subject: Re: BUG #4860: Indexes gone after restore