Thread: just upgraded from 7.0 to version 7.3 problem with pg_dump

just upgraded from 7.0 to version 7.3 problem with pg_dump

From
Christoph Schmidt
Date:
Sorry, if this comes twice.
I sent it and didn't receive it myself.

Hi, I just downloaded 7.3 and
was a bit suprised.
Most things become better.
But
what I am missing is that :

1st the standard SQL says that
the create Table format should look like :
create table (
        column1 .....,
        column2 .....,
        .
        .
        columnn......,
        foreign key (......).....
);

But postgreSQL decided to put the foreign key-clause
yust behind the column-definition !
Why ???

2snd :
if you make a pg_dump, you will get
a list of create table statements - thats ok :-)
but  there is -- different to the declaration --
no foreign key clause.
may be some hundred lines below you will
find :
ALTER TABLE ONLY aaa
    ADD CONSTRAINT "$1" FOREIGN KEY (art_id_no) REFERENCES
bbb(art_id_no) ON UPDATE CASCADE ON DELETE CASCADE;

or something similar.

So why not the standard ?
and
why not the same format as in the declaration ?

If you want to document or to transfer from one database
to another it was (version 7.0 and before) better or easier
to do it.

Even if the former versions didn't support foreign keys
you could use the standard SQL-syntax.


Is there any way to make a dump in the old format ?????

If someone could give me a short instruction - and it is not toooo
difficult -- I would like to try a patch ??
or (and this is not so nice but may be easier) write a tool
or routine inside the pg_dump - code
which will do what I want. ?

(keep foreign key  clause as a part of the definition and not as an
alter table
many lines later)

cs

Re: just upgraded from 7.0 to version 7.3 problem with pg_dump

From
Tom Lane
Date:
Christoph Schmidt <cs.wiechs.ar@swol.de> writes:
> So why not the standard ?

You can write it in the standard syntax if you wish.

pg_dump has its own reasons for using ALTER TABLE (which btw is also
fully standard): it wants to postpone creating indexes until after it's
done the bulk data loading, for speed reasons.

            regards, tom lane