Re: pg_dump is broken in CVS tip

Поиск
Список
Период
Сортировка
От Neil Conway
Тема Re: pg_dump is broken in CVS tip
Дата
Msg-id 20020412184417.62eeb74e.neilconway@rogers.com
обсуждение исходный текст
Ответ на pg_dump is broken in CVS tip  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Tycho Fruru
Дата:
Сообщение: Re: [GENERAL] [Fwd: AW: More UB-Tree patent information]
Следующее
От: Jean-Luc Lachance
Дата:
Сообщение: Re: [GENERAL] [Fwd: AW: More UB-Tree patent information]