Skip site navigation (1) Skip section navigation (2)

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 (view raw or flat)
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

pgsql-bugs by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group