Re: Anyone working on pg_dump dependency ordering?

From: Andreas Pflug <pgadmin(at)pse-consulting(dot)de>
To: Rod Taylor <pg(at)rbt(dot)ca>
Cc: Stephan Szabo <sszabo(at)megazone(dot)bigpanda(dot)com>, Christopher Kings-Lynne <chriskl(at)familyhealth(dot)com(dot)au>, PostgreSQL Development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Anyone working on pg_dump dependency ordering?
Date: 2003-11-22 23:02:10
Message-ID: 3FBFEAF2.8020700@pse-consulting.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Rod Taylor wrote:

>
>
>CREATE TABLE a (col integer primary key);
>CREATE TABLE b (col integer primary key);
>ALTER TABLE a ADD FOREIGN KEY (col) REFERENCES b INITIALLY DEFERRED;
>ALTER TABLE b ADD FOREIGN KEY (col) REFERENCES a;
>
>How does MSSQL deal with the above?#
>
>
It depends. Restricting FKs are generated silently, while ON DELETE
CASCADE will throw a message and refuse to create. MSSQL doesn't know
about deferred FKs; no chance to enter spuriously inconsistent data.
Still, using cyclic references is IMHO bad design style. I can't accept
an exceptional case as reason to break *all* table's definition into
pieces. The CREATE TABLE syntax shows that I'm probably not the only one
thinking like this: it may include all constraint definitions as well.

There might be discussions whether its better to script
CREATE TABLE xxx ..;
ALTER TABLE xxx ADD PRIMARY KEY ....;
ALTER TABLE xxx ADD FOREIGN KEY ....;
or
CREATE TABLE xxx (...., PRIMARY KEY (..), FOREIGN KEY (..));

I'd opt for the second version (a little formatted, maybe :-)

Regards,
Andreas

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Rod Taylor 2003-11-22 23:47:19 Re: Anyone working on pg_dump dependency ordering?
Previous Message Greg Stark 2003-11-22 22:24:08 Re: Sponsoring enterprise features