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
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 |