From: | Albert Cervera Areny <albertca(at)hotpop(dot)com> |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Inheritance, Primary Keys and Foreign Keys |
Date: | 2006-05-12 22:35:02 |
Message-ID: | 200605130035.03117.albertca@hotpop.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Of course, that's an option for my case. Just wanted to know if this solution
could be useful for PostgreSQL in general. Mainly because I'll add some
triggers to check what maybe PostgreSQL should do itself but it's
unimplemented.
If that's not interesting or a proper solution for PostgreSQL I'll add it
using the existing DDL in my application and that's all.
What do you think?
A Tuesday 09 May 2006 21:43, Simon Riggs va escriure:
> On Tue, 2006-05-09 at 01:20 +0200, Albert Cervera Areny wrote:
> > In my particular case (don't know about the SQL standard or other
> > cases), it'd be enough if when an inherited table is created:
> > - A primary key in the inherited table is created with the same columns
> > as the super table.
> > - A trigger is created in the new table that ensures that this primary
> > key doesn't exist in the super table.
> > - A trigger is created in the super table that ensures that this primary
> > key doesn't exist in it's sub tables.
>
> Why not add these in your design rather than into the database?
>
> All of the above can be added using existing DDL and you can group
> things together in a transaction and call when required.
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2006-05-12 22:39:44 | Re: DH_check return value test correct? |
Previous Message | Jim C. Nasby | 2006-05-12 19:05:59 | Re: audit table containing Select statements submitted |