The following bug has been logged online:
Bug reference: 3048
Logged by: Dmitry Koterov
Email address: d@koterov.ru
PostgreSQL version: 8.2.0
Operating system: Linux
Description: pg_dump dumps intarray metadata incorrectly
Details:
Steps to reproduce:
1. create database ti;
2. <run SQL initialization code for intarray>
3. pg_dump -i -h YourHost -U YourLogin ti > s.sql
4. drop database ti; create database ti;
5. <run SQL produced by pg_dump (s.sql)>
You will get a message:
ERROR: could not make operator class "gin__int_ops" be default for type
pg_catalog.int4[]
DETAIL: Operator class "_int4_ops" already is the default.
Seems the problem is in the operator
CREATE OPERATOR CLASS gin__int_ops
DEFAULT FOR TYPE integer[] USING gin AS
STORAGE integer ,
OPERATOR 3 &&(integer[],integer[]) ,
OPERATOR 6 =(anyarray,anyarray) RECHECK ,
OPERATOR 7 @>(integer[],integer[]) ,
OPERATOR 8 <@(integer[],integer[]) RECHECK ,
OPERATOR 13 @(integer[],integer[]) ,
OPERATOR 14 ~(integer[],integer[]) RECHECK ,
OPERATOR 20 @@(integer[],query_int) ,
FUNCTION 1 btint4cmp(integer,integer) ,
FUNCTION 2 ginarrayextract(anyarray,internal) ,
FUNCTION 3 ginint4_queryextract(internal,internal,smallint) ,
FUNCTION 4 ginint4_consistent(internal,smallint,internal);
produced by pg_dump. This is likely because of the operator
--mark built-in gin's _int4_ops as non default
update pg_opclass set opcdefault = 'f' where
pg_opclass.opcamid = (select pg_am.oid from pg_am where amname='gin') and
opcname = '_int4_ops';
inside intarray initialization SQL code: pg_dump knows nothing about them in
the stage of scheme creation.
So, now it is impossible to dump+restore a database containing intarray
metadata.
