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