Re: BUG #3048: pg_dump dumps intarray metadata incorrectly - Mailing list pgsql-bugs

From Dmitry Koterov
Subject Re: BUG #3048: pg_dump dumps intarray metadata incorrectly
Date
Msg-id d7df81620702231159w4351a73awbf8c371944a4eea1@mail.gmail.com
Whole thread Raw
In response to Re: BUG #3048: pg_dump dumps intarray metadata incorrectly  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-bugs
Maybe possibly remove DEFAULT definition from the intarray initialization
SQL and eliminate in the documentation: "if you want to use GIN with _int4,
you have to specify the operator class explicitly and manually"? This at
least does not break the standard pg_dump behaviour. We checked, if we
remove DEFAULT keyword, a dump is restored correctly.

On 2/23/07, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> "Dmitry Koterov" <d@koterov.ru> writes:
> > [ pg_restore fails with ]
> > 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.
>
> Yeah.  I'd say that intarray's attempt to override the default status of
> the built-in gin opclass is simply a bad idea and should be removed.
> It's not even documented that it does that (in fact I see no mention of
> GIN at all in README.intarray :-(, so we have a documentation lack
> here too).
>
> Comments?
>
>                         regards, tom lane
>

pgsql-bugs by date:

Previous
From: "Axel Noltemeier"
Date:
Subject: BUG #3067: Unnecessary lock blocks reindex
Next
From: Rich Teer
Date:
Subject: Re: BUG #2969: Inaccuracies in Solaris FAQ