Re: [SQL] Re: [GENERAL] Proposed Changes to PostgreSQL - Mailing list pgsql-hackers

From Chris Bitmead
Subject Re: [SQL] Re: [GENERAL] Proposed Changes to PostgreSQL
Date
Msg-id 3898FC60.E4436ED5@nimrod.itg.telecom.com.au
Whole thread Raw
In response to Re: [GENERAL] Proposed Changes to PostgreSQL  (Bruce Momjian <pgman@candle.pha.pa.us>)
List pgsql-hackers
Tom Lane wrote:
> >>>> This bothers me.  We return relational data, showing the same number of
> >>>> columns and types for every query.  I don't think we want to change
> >>>> that, even for OO.
> 
> My thought also.  If we had a *real* object orientation, then a returned
> column would have an abstract data type that might correspond to an
> object supertype.  Of course that just pushes the problem down a level:
> how does the application know what methods the returned object has?
> How can it even invoke those methods --- whatever code might exist
> for them would live on the server, presumably, not get shipped around
> in query results.

In (most) ODBMSes, the code for a class does NOT live in the database
server. (How
would you store a C++ binary in a database?).

What happens is when a query returns an object, some magic behind the
scenes
checks the type of the returned object (thus the need for the
"classname" column
or similar.) The magic behind the scenes then instantiates a C++ object
of
the correct class and populates all the data members from the query
results.

The application code is then free to make polymorphic calls on the
object
because ALL the fields are populated, not just those of the base class.


pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: [HACKERS] Re: [SQL] Re: [GENERAL] Proposed Changes to PostgreSQL
Next
From: Chris Bitmead
Date:
Subject: Re: [HACKERS] Re: [SQL] Proposed Changes to PostgreSQL