Seastian Böck wrote:
for primary keys there is a simple (and at least working for me) solution as long as you can use the SERIAL type for your primary key. [...] Now the id column gets merged and you should have the desired behaviour.
If you want objects.id to get referenced by other tables you have to work around with triggers and an extra table. For persons.id everything is working fine.
This solution (workaround) is only working as long you don't insert id-values without updating the corresponding sequence.
Hello Se(b)astian -- you left out the 'b' in your e-mail setup ;)
right, your proposal does in a way behave like I wanted. Though the idea of integrity control by the db-server is still not there for parent id-colomns. Every user or application could mess up the primary key of the inherited table. That spoils a bit of the oo-approach, I fear.
I rechecked that and the conclusion is very simple: it only works reliable if the id is autogenerated by the SERIAL type.
It wouldn't be that bad, if the table contents weren't merged in SELECTs.
Probaply one could do some trigger-magic to check the inserted id against an id-pool in another table.
If one knew anything about triggers that is ... well ... miles to go before I sleep ...
For all other situations take a look at Oliver's mail.
Sebastian
---------------------------(end of broadcast)--------------------------- TIP 7: don't forget to increase your free space map settings
