Re: BUG #3048: pg_dump dumps intarray metadata incorrectly

From: "Dmitry Koterov" <dmitry(at)koterov(dot)ru>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-bugs(at)postgresql(dot)org, "Oleg Bartunov" <oleg(at)sai(dot)msu(dot)su>, "Teodor Sigaev" <teodor(at)sigaev(dot)ru>
Subject: Re: BUG #3048: pg_dump dumps intarray metadata incorrectly
Date: 2007-02-23 19:59:00
Message-ID: d7df81620702231159w4351a73awbf8c371944a4eea1@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> "Dmitry Koterov" <d(at)koterov(dot)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
>

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Rich Teer 2007-02-23 20:08:03 Re: BUG #2969: Inaccuracies in Solaris FAQ
Previous Message Peter Eisentraut 2007-02-23 19:56:29 Re: BUG #2969: Inaccuracies in Solaris FAQ