Re: [HACKERS] It would be nice if this could be fixed...

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