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.