Re: pg_dump is broken in CVS tip - Mailing list pgsql-hackers

From Neil Conway
Subject Re: pg_dump is broken in CVS tip
Date
Msg-id 20020412184417.62eeb74e.neilconway@rogers.com
Whole thread Raw
In response to pg_dump is broken in CVS tip  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Fri, 12 Apr 2002 13:28:34 -0400
"Tom Lane" <tgl@sss.pgh.pa.us> wrote:
> pg_dumping a table having a primary key yields commands like
> 
> --
> -- TOC Entry ID 2 (OID 139812)
> --
> -- Name: table1 Type: TABLE Owner: postgres
> --
> 
> CREATE TABLE "table1" (
>     "column10" character varying(255) NOT NULL,
>     "column1" character varying(255) NOT NULL,
>     "column2" smallint NOT NULL,
>     "column6" numeric,
>     "column7" "char",
>     Constraint "table1_pkey" Primary Key ("column10", "column1", "column2")
> );
> 
> [snip]
> 
> --
> -- TOC Entry ID 5 (OID 139817)
> --
> -- Name: "table1_pkey" Type: CONSTRAINT Owner: postgres
> --
> 
> Alter Table "table1" Add Constraint "table1_pkey" Primary Key ("column10", "column1", "column2");
> 
> which on execution quite properly complains about duplicate primary
> keys.

Thanks for finding this Tom -- my apologies, this is likely my bug.

However, when I created a table using the commands above and then
dumped it again, I got a dump that worked properly: there was no
Constraint within the table definition itself, just an ALTER
TABLE at the end of the dump to add the PK (i.e. the patch worked
as intended and the table could be restored properly).

If you can give me a reproduceable test-case, I'll fix the bug.

Cheers,

Neil

-- 
Neil Conway <neilconway@rogers.com>
PGP Key ID: DB3C29FC


pgsql-hackers by date:

Previous
From: Tycho Fruru
Date:
Subject: Re: [GENERAL] [Fwd: AW: More UB-Tree patent information]
Next
From: Jean-Luc Lachance
Date:
Subject: Re: [GENERAL] [Fwd: AW: More UB-Tree patent information]