Re: argtype_inherit() is dead code

> -----Original Message-----
> From: Jim C. Nasby [mailto:decibel(at)decibel(dot)org]
> Sent: Tuesday, April 19, 2005 5:56 PM
> To: Christopher Browne
> Cc: pgsql-hackers(at)postgresql(dot)org
> Subject: Re: [HACKERS] argtype_inherit() is dead code
>
> [...]
> On Sun, Apr 17, 2005 at 07:01:41PM -0400, Christopher Browne wrote:
> > [...]
> > "Object Orientation" is all about the notion of having data that
> > is aware of its type, and where there can be a dispatching of
> > methods against those types.
> >
> > There is already a perfectly functional ability to dispatch based
> > on argument types.
> >
> > These essentials are there.

Well, if you go with Bjarne Stroustrup's formulation of OOP (which is,
of course, by no means exclusively authoritative), the core of OOP
is encapsulation, inheritance, and polymorphism. Inherited tables
provide the second, overloaded functions provide the third, but
the security model is left providing the first. However, I would say
that the first property is the most essential for OOP, because in my
view, OOP is about *data hiding*. In particular, it's about separating
the implementation from the interface, and forcing users to access
objects through the interface. While such a design philosophy is
*possible* with Postgres, it is by no means encouraged or *easy*.
Furthermore, it probably doesn't make sense in all contexts.

One way to think about an object-relational database is as a set of
persistent objects stored in well-known containers. While traditional
programming languages offer several common access methods for
containers, the point of a query language is to offer an extremely
powerful and generalized container access system. However, this
access system is really an implementation detail of the object system,
while at the same time being the primary means of object interaction.

In terms of manipulating data, it's really about as OOP as passing
around raw pointers to everything. From this perspective, DBs will not
support OOP while SQL remains the primary access method; and there is
no reason to believe that people will give up SQL in favor of a more
OOP-like interface.

> Yes, but they're only there when it comes to storing data. There's
> nothing allowing you to cohesively combine code and data.

I agree entirely. And I also agree that in many cases, there is no
sensible way to do so. One of the ways in which DBs are different from
programming language objects is in the data decomposition. Most PLs
have self-contained objects whose data is primarily localized within
one structure that is more or less contiguous in memory. DBs, on the
other hand, tend to have objects that may span multiple tables, because
this is the most efficient way of storing the data. In a way, the
relational model is the antithesis of the OOP model. The central theme
of the relational model is *data-sharing*. The idea that data should
be decomposed and the common pieces factored out. Whereas, OOP says
that it is the *functionality* that should be factored out into a
minimal interface.

> An object should be able to have methods attached to it, for example.

I don't think that's sufficient. To support encapsulation, you also
need to enforce access to the data through the method interface. Else,
you can simulate methods with stored procedures.

> And that functionality is essentially missing. There's no way to
> present a combined set data and code that operates on that data.

That's encapsulation. And it's missing. But for a good reason.

> It doesn't really matter why this kind of functionality is missing;
> the fact that it is missing means it's much less likely that any of
> the OO stuff will be used.

Actually, it *does* matter why it's missing. The reason it's missing
tells us why people don't use the OOP features of the DB. What needs
to be done is to construct a consistent theory of how the relational
model and the OOP model can be integrated. The OOP model is about
data integrity, maintaining object invariants, ensuring program
correctness, etc. The relational model is about performance, storing
data efficiently, querying it efficiently, etc. These are competing
goals, and it may well be that a good object-relational theory simply
develops a framework in which the tradeoffs are explicitly stated
and describes how to implement different points in the design space
in a consistent way. I realize that there is some existing work
with object-relational modelling, but my impression is that such
work is still fairly immature and scattered.

> I think the current limitations (foreign keys, and cross-table
> constraints) are issues as well. It might also help if the
> docs had some info about how inherited tables worked 'under the
> covers', so people knew what kind of overhead they implied.

I don't think inherited tables work in an entirely intuitive way. It
certainly doesn't help that viewing an inherited table through pgAdmin
shows records that aren't returned by an equivalent query. I think
the problem is that OOP concepts have been "bolted on" to the
relational model without really thinking hard about what functionality
should be available to really support ORM.

__
David B. Held
Software Engineer/Array Services Group
200 14th Ave. East, Sartell, MN 56377
320.534.3637 320.253.7800 800.752.8129