Hi Jeff,
this is worse news than I expected -- I had that that at least somebody
would be playing around with this...
Of course there is a price to pay for OO functionality -- but is there
evidence that, given I tweak the frontend into such a direction,
PostreSQL due to its backend architecture will do really significantly
slower than OODBMS/ORDBMS more specialized for that sake (the same with
rules...)?? Or is it worth to give it a try?
This would be my last resort,
Nick
> Although postgres at one time had "ORDBMS" as a goal, I haven't seen any
> real interest or work in that area for a long time. The OO features are
> primarily:
>
> 1. OIDs -- hidden columns with auto-generated number.
>
> At one time, OIDs were a part of every table,
;-)) The time when I began using PostgreSQL...
> now they must be specified
> explicitly. They still remain on many of the system catalogs, but not
> all. Mostly, they are now just an implementation detail that people only
> notice when looking at the catalogs (and I am personally annoyed that
> they are hidden, because when looking at the catalogs usually you want
> to see the OIDs).
>
> 2. Inheritance
>
> This feature is now used almost exclusively for physical partitioning
> rather than logical design.
>
> Nick, I think the problem with ORDBMS is that they essentially introduce
> pointers in the data, and that adds a lot of complexity.
>
> For instance, the relational algebra has nice closure properties. If you
> join two relations, you get another relation.
>
> But what if you introduce pointers? Well, then each table might start
> out with OIDs, but then when you join with another table and do a GROUP
> BY, you lose any meaningful OIDs. So what do you have? Something else.
> Therefore, you've lost closure.
>
> Now, maybe there is a good reason to sacrifice closure and other nice
> properties of the relational model. But there is a perception among many
> people (like Andy) that the case has not been made.
>
> Regards,
> Jeff Davis
>
>
>