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 по дате отправления:

Предыдущее
От: Peter Eisentraut
Дата:
Сообщение: Re: Bug #579: Auto-VACUUM doesnt work
Следующее
От: pgsql-bugs@postgresql.org
Дата:
Сообщение: Bug #580: Optimizer uses seq scan only