Alvaro Herrera skrev: > Nis Jørgensen wrote: > >> What if, for instance, I want to render a list of shapes? >> >> To render the shape, I need to get its data, to get its data, I >> need to know what type it is. ISTM that the easiest way to achieve >> this is storing the type info at the "top" of the table hierarchy. > > Try adding "tableoid" to the list of columns retrieved. Even better, > cast that to regclass. This is if I use PG table inheritance, right? This might be a solution to the problem of the OP. I have stayed away from that solution however, mostly because of this bit from the documentation: > A serious limitation of the inheritance feature is that indexes > (including unique constraints) and foreign key constraints only apply > to single tables, not to their inheritance children. This is true on > both the referencing and referenced sides of a foreign key > constraint. This to me means that the builin inheritance is less powerful than what I can build myself (although multiple inheritance is nice, and quite hard to implement using the shared-fields model). Nis
