Jan Wieck wrote:
> Not exactly, because in his example there is only one table
> used in the view. But I wonder what an OID from a view might
> be good for?
The problem with postgres, unlike other object models, is that you can't
add methods to objects, except by creating a new "object" called a view.
(Well I suppose you can write functions or something, but it's not
invisible to the user like a view).
So users start using base tables and their oids and doing SELECTs. Then
someone realises they need a "method" (like quantity * price AS total or
something), so they make a view, and they want to start using the view.
But they want to avoid changing references to "oid" to some new name in
the view.
> Under normal conditions, the OID is only good to
> UPDATE/DELETE something that was first SELECTed and later
> qualified by the application. But this is BAD design,
> because any system attribute is DB specific and leads to
> application portability problems.
A unique identifier for an object is NOT Db specific in the object
database ODMG world. I want to use Postgres like a bad Object database,
not like a good RDBMS.
I'd like to put up a web page soon to list what needs to be done to
Postgres in order for it to support the Object Database Management Group
(ODMG) standard. The basic answer is "not a lot", but there are a few
things. One thing to understand is that for an object database, the oid
is absolutely fundamental.
Anyway, Postgres is portable, so by extension my app is portable if I
use it.
--
Chris Bitmead
http://www.bigfoot.com/~chris.bitmead
mailto:chris.bitmead@bigfoot.com
