Re: [HACKERS] pg_dump problem?

Then <chris.bitmead@bigfoot.com> spoke up and said:
> I don't give a rip about standard SQL. What I care about is real object
> databases. A fundamental principle of object theory is that objects have
> a unique identity. In C++ it is a pointer. In other languages it is a
> reference. In an object database it is an oid. In the NSHO of a fellow
> called Stonebraker, you should be using oids for everything.

Unfortunately, the implementation within PostgreSQL suffered from both
bugs and severe logic errors.  Further there was no facility for
manipulating OIDs (can you say dump/reload?).  Thanks to the efforts
of the PostgreSQL community, many of these items have been fixed, but
sometimes at a cost to OO.

> BTW, I was looking through the original 4.2 docs, and I noted that in
> Postgres 4.2 every class had not only an oid, but an implicit classoid,
> allowing you to identify the type of an object. What happened to this?
> It would solve just a ton of problems I have, because I'm using a very
> OO data model. It sounds like Postgres used to be a real object
> database. Now everybody seems to want to use it as yet another sucky rdb
> and a lot of essential OO features have undergone bit-rot. What happened
> to building a better mouse trap? 

We (not really me, but the others who are actually writing code) are
working very hard to make PostgreSQL SQL92 compliant and stable.
Further, more features are being added all the time.  If you want a
particular feature set, then get off your butt and contribute some
code.  When I wanted PostgreSQL to work on my AViiON, I did the
necessary work and contributed it back to the community.

> Have a read of shared_object_hierarchy.ps in the original postgres doco
> to see how things should be done. Sorry for the flames, but I used to
> work for an ODBMS company and I'm passionate about the benefits of
> properly supporting objects.

Cool.  Take your experience and write some code.  BTW, you might want
to notice that document was never a description of how things *really*
worked in PostgreSQL, only how it was *supposed* to work.  We
inherited some seriously broken, dysfunctional code and have done some
beautiful work with it (again, not actually me here).  It's a work in
progress, and therefore should be looked at by the users as 
a) needing work, and
b) an opportunity to excell, by showing off your talents as you submit
new code.

-- 
=====================================================================
| JAVA must have been developed in the wilds of West Virginia.      |
| After all, why else would it support only single inheritance??    |
=====================================================================
| Finger geek@cmu.edu for my public key.                            |
=====================================================================