Обсуждение: pg_dump object dump-order

Поиск
Список
Период
Сортировка

pg_dump object dump-order

От
KL
Дата:
Greetings


I'm working with PostgreSQL for quite some time now
but only yesterday ran into a specific problem, as - so far -
I have always used customized backup/restore-scripts.

PROBLEM:
pg_dump seems to dump objects strictly alphabetically,
I presume. Hence a table "events" is always dumped
_before_ any sequence "events_id_seq" that is already
being referenced in the "create table"-statement for
table "events".

Example

CREATE TABLE event (
 event_id integer DEFAULT nextval('event_id_seq'::text) NOT NULL,
 .
 .
 .
);

ALTER TABLE public.event OWNER TO someuser;

--
-- Name: event_id_seq; Type: SEQUENCE; Schema: public; Owner: someuser
--

CREATE SEQUENCE event_id_seq
    INCREMENT BY 1
    NO MAXVALUE
    NO MINVALUE
    CACHE 1;


This ordering results in an error upon importing the data
with "psql".

QUESTION:
Is there any solution/option/trick/secret/whatever
to make pg_dump export referenced objects _before_
they are being referenced?

Thanks in advance


PS:
The thing isn't really urgent, as I have my "custom"-scripts
anyway, but it could be convenient to just have pg_dump
and psql as reliable, "out-of-the-box"-fallback-options.

I searched the lists here and also googled the whole day,
but couldn't find anything appropriate. Should there be
a thread about this issue already, I'd like to apologize
in advance.



Re: pg_dump object dump-order

От
Tom Lane
Дата:
KL <zappa_lot@gmx.net> writes:
> pg_dump seems to dump objects strictly alphabetically,

No, it doesn't ... at least not if you are running 8.0 or later.
It looks at dependencies to see what has to be dumped first.
(It does prefer alpha order when there's no dependency constraint.)

There are various situations where there might not be a dependency
entry, but without knowing more about the history of the table and
exactly which version you're running, it's hard to speculate about
why or what's the best fix.

I will point out, however, that the given script does not in fact
fail to load in any Postgres version known to me.  Maybe you should
post your real problem instead of an oversimplified example.

            regards, tom lane