From: | "Stephan Szabo" <sszabo(at)kick(dot)com> |
---|---|
To: | "Philip Warner" <pjw(at)rhyme(dot)com(dot)au> |
Cc: | <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: pg_dumpall and check constraints |
Date: | 2000-07-01 02:12:12 |
Message-ID: | 001501bfe301$c5e847f0$0c64010a@kick.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
> > How should a RESTRICT or ON
> > DELETE CASCADE work in that scenario?
>
> Perhaps as Check constraints on all tables in the view...for the most part
> I would not expect complex views to be used in this way, but since this is
> what the user would have to do anyway, why not do it for them?
I'd say that for right now, way to complicated... Any non-trivial view
would be an incredible pain. Although, once we properly insist on there
being a unique constraint on the columns referenced, it would probably
be easier (although can you actually put a unique constraint on a view?)
Take, for example,
create view x as select a.id, c.name from a,b,c where a.id=b.id and
a.type=c.type
and b.customerid=c.id and c.name < 'Smith';
So, what it the deletion constraint on table c? It's something like, you
can't delete
a row in c that has a name < 'Smith' and who matches up with an a,b row
based on
the other constraints and has a referencing row in the table you made the
reference
from, but I'm not even 100% sure of that. And heaven help you if there are
subqueries.
And of course, the cascade, set null and set default are even stranger.
From | Date | Subject | |
---|---|---|---|
Next Message | Thomas Lockhart | 2000-07-01 02:56:53 | Re: Performance of Postgres via network connections |
Previous Message | Philip Warner | 2000-07-01 00:25:14 | Re: pg_dumpall and check constraints |