Re: Bug #578: pg_dumpall from 7.1.3 can not be imported in 7.2.0
От | Tom Lane |
---|---|
Тема | Re: Bug #578: pg_dumpall from 7.1.3 can not be imported in 7.2.0 |
Дата | |
Msg-id | 15023.1013456768@sss.pgh.pa.us обсуждение исходный текст |
Список | pgsql-bugs |
"Rainer Tammer" <tammer@tammer.net> writes: > On Mon, 11 Feb 2002 08:20:39 -0800 (PST), Stephan Szabo wrote: >> I see a check constraint on queue which says q_short<>''::text >> and the same on category. Did you rename q_short as either >> q_name or q_group? I know there's a bug that the reported >> name for the check constraint doesn't follow a alter table >> rename column properly. > Yes I did alter the following tables: queue, category > shd=# \d queue > Table "queue" > Attribute | Type | Modifier > -----------+---------+-------------------------------------------------- > q_id | integer | not null default nextval('queue_q_id_seq'::text) > q_name | text | not null > q_group | text | not null > Indices: queue_pkey, > queue_q_name_key > Constraints: (q_short <> ''::text) > (q_name <> ''::text) Ah so. The problem here is that pg_relcheck.rcsrc doesn't track column renaming. One wonders why we have the column at all :-( > Now the question: > How can I correct this error. Either edit the dump file, or manually update the pg_relcheck.rcsrc field for that constraint. As far as fixing the problem in the long term goes, I wonder if we should change pg_dump to use pg_get_expr(rcbin) in place of rcsrc. I seem to recall a discussion a long time back about whether it was better to store constraints in source or expression-tree form. This shows one case where the expression-tree is more robust... regards, tom lane
В списке pgsql-bugs по дате отправления: