Uh, I believe this has not been done.
Your patch has been added to the PostgreSQL unapplied patches list at:
http://momjian.postgresql.org/cgi-bin/pgpatches
It will be applied as soon as one of the PostgreSQL committers reviews
and approves it.
-
Oleg, I still haven't seen this patch applied to CVS.
---
Oleg Bartunov wrote:
> On Mon, 2 Apr 2007, Bruce Momjian wrote:
>
> > Tom Lane wrote:
> >> Bruce Momjian <[EMAIL PROTECTED]> writes:
> >>> Tom, do you want this fixe
But it should dump them as "ALTER whatever" commands, right?
No :(, see
http://archives.postgresql.org/pgsql-hackers/2007-03/msg01112.php
about ALTER OPERATOR CLASS
--
Teodor Sigaev E-mail: [EMAIL PROTECTED]
Oleg Bartunov wrote:
> On Mon, 2 Apr 2007, Bruce Momjian wrote:
>
> >Tom Lane wrote:
> >>Bruce Momjian <[EMAIL PROTECTED]> writes:
> >>>Tom, do you want this fixed for 8.2.X?
> >>
> >>>Tom Lane wrote:
> Yeah. I'd say that intarray's attempt to override the default status of
> the built-in
On Mon, 2 Apr 2007, Bruce Momjian wrote:
Tom Lane wrote:
Bruce Momjian <[EMAIL PROTECTED]> writes:
Tom, do you want this fixed for 8.2.X?
Tom Lane wrote:
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 rem
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Tom, do you want this fixed for 8.2.X?
>
> > Tom Lane wrote:
> >> 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.
>
> I don't recall h
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Tom, do you want this fixed for 8.2.X?
> Tom Lane wrote:
>> 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.
I don't recall having seen a response from Oleg
Tom, do you want this fixed for 8.2.X?
---
Tom Lane wrote:
> "Dmitry Koterov" <[EMAIL PROTECTED]> writes:
> > [ pg_restore fails with ]
> > ERROR: could not make operator class "gin__int_ops" be default for type
> > pg_cata
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
remo
"Dmitry Koterov" <[EMAIL PROTECTED]> 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 statu
The following bug has been logged online:
Bug reference: 3048
Logged by: Dmitry Koterov
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.2.0
Operating system: Linux
Description:pg_dump dumps intarray metadata incorrectly
Details:
Steps to reproduce:
1. create
11 matches
Mail list logo