| From: | "Zeugswetter Andreas SB SD" <ZeugswetterA(at)spardat(dot)at> |
|---|---|
| To: | "Curt Sampson" <cjs(at)cynic(dot)net>, "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | "Greg Copeland" <greg(at)CopelandConsulting(dot)Net>, "Christopher Kings-Lynne" <chriskl(at)familyhealth(dot)com(dot)au>, "PostgresSQL Hackers Mailing List" <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Inheritance |
| Date: | 2002-08-16 08:19:54 |
| Message-ID: | 46C15C39FEB2C44BA555E356FBCD6FA4961E4A@m0114.s-mxs.net |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
> > It's nonlocal constraints that are the problem, and here foreign keys
> > and UNIQUE constraints are certainly the canonical examples. Both of
> > these would be largely solved with table-spanning indexes I think.
>
> Note that the other obvious way to solve this would be to store all of
> the information inherited from the parent in the parent table, so that
> you don't have to do anything special to make all of the constraints and
> whatnot apply.
Seems with above you are not able to constrain what qualifies for a supertable row,
you would only be able to specify constraints that apply to all it's subtables.
To me, the current implementation looks superior and more efficient.
The SQL inheritance is a class/subclass thing.
All tables have instances (==rows) that are not (by itself) related.
(Even if they happen to share all attribute values with another row of a supertable.)
If you want that, then you need to resort to 3NF (or ROWREF's which iirc is another
SQL99 feature).
Andreas
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Iavor Raytchev | 2002-08-16 08:40:22 | Re: Companies involved in development |
| Previous Message | Oleg Bartunov | 2002-08-16 07:25:15 | Re: tsearch bug in 7.2.1? |