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. ---------------------------(end of broadcast)--------------------------- TIP 6: explain analyze is your friend
