> -----Original Message----- > From: Jim C. Nasby [mailto:[EMAIL PROTECTED] > Sent: Tuesday, April 19, 2005 5:56 PM > To: Christopher Browne > Cc: pgsql-hackers@postgresql.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 ---------------------------(end of broadcast)--------------------------- TIP 4: Don't 'kill -9' the postmaster
