Thread: argtype_inherit() is dead code

argtype_inherit() is dead code

From
Tom Lane
Date:
In parse_func.c there are routines argtype_inherit() and
gen_cross_product() that date from Berkeley days.  The comments
explain their reason for existence thus:
*  This function is used to handle resolution of function calls when*  there is no match to the given argument types,
butthere might be*  matches based on considering complex types as members of their*  superclass types (parent
classes).** It takes an array of input type ids.  For each type id in the array*  that's a complex type (a class), it
walksup the inheritance tree,*  finding all superclasses of that type. A vector of new Oid type*  arrays is returned to
thecaller, listing possible alternative*  interpretations of the input typeids as members of their superclasses*
ratherthan the actually given argument types. The vector is*  terminated by a NULL pointer.**  The order of this vector
isas follows:  all superclasses of the*  rightmost complex class are explored first.  The exploration*  continues from
rightto left.  This policy means that we favor*  keeping the leftmost argument type as low in the inheritance tree*  as
possible. This is intentional; it is exactly what we need to*  do for method dispatch.**  The vector does not include
thecase where no complex classes have*  been promoted, since that was already tried before this routine*  got called.
 

I realized that this is effectively dead code: although it can be
executed, it can never produce any useful results.  The reason is that
can_coerce_type() already knows that inherited rowtypes can be promoted
to their parent rowtypes, and it considers that a legal implicit
coercion.  This means that any possible function matches based on
promoting child rowtypes to ancestors were found in func_get_detail()'s
first pass.  If there is exactly one match then it will be taken as
the correct answer and returned without calling argtype_inherit().
If there is more than one match then func_get_detail() will fail
(return FUNCDETAIL_MULTIPLE), again without calling argtype_inherit().
The only way to reach argtype_inherit() is if there are *no* ancestor
matches, which means that the function is a very expensive no-op that
we execute just before throwing an error.

I'm strongly tempted to just rip out argtype_inherit() and
gen_cross_product().  Even if we suppose that we might want to resurrect
the claimed functionality someday, I don't think it could be made to
work this way.  You'd have to put the knowledge into
func_select_candidate() instead, else there'd be very weird interactions
with the heuristics for resolving non-complex input argument types.

Thoughts?
        regards, tom lane


Re: argtype_inherit() is dead code

From
elein@varlena.com (elein)
Date:
Are you saying that the code was supposed "unflatten" the
arguments of a function into a possible composite type taking into
consideration the possible inheritance information of the
composite type?

elein

On Fri, Apr 15, 2005 at 08:04:36PM -0400, Tom Lane wrote:
> In parse_func.c there are routines argtype_inherit() and
> gen_cross_product() that date from Berkeley days.  The comments
> explain their reason for existence thus:
> 
>  *  This function is used to handle resolution of function calls when
>  *  there is no match to the given argument types, but there might be
>  *  matches based on considering complex types as members of their
>  *  superclass types (parent classes).
>  *
>  *  It takes an array of input type ids.  For each type id in the array
>  *  that's a complex type (a class), it walks up the inheritance tree,
>  *  finding all superclasses of that type. A vector of new Oid type
>  *  arrays is returned to the caller, listing possible alternative
>  *  interpretations of the input typeids as members of their superclasses
>  *  rather than the actually given argument types. The vector is
>  *  terminated by a NULL pointer.
>  *
>  *  The order of this vector is as follows:  all superclasses of the
>  *  rightmost complex class are explored first.  The exploration
>  *  continues from right to left.  This policy means that we favor
>  *  keeping the leftmost argument type as low in the inheritance tree
>  *  as possible.  This is intentional; it is exactly what we need to
>  *  do for method dispatch.
>  *
>  *  The vector does not include the case where no complex classes have
>  *  been promoted, since that was already tried before this routine
>  *  got called.
> 
> I realized that this is effectively dead code: although it can be
> executed, it can never produce any useful results.  The reason is that
> can_coerce_type() already knows that inherited rowtypes can be promoted
> to their parent rowtypes, and it considers that a legal implicit
> coercion.  This means that any possible function matches based on
> promoting child rowtypes to ancestors were found in func_get_detail()'s
> first pass.  If there is exactly one match then it will be taken as
> the correct answer and returned without calling argtype_inherit().
> If there is more than one match then func_get_detail() will fail
> (return FUNCDETAIL_MULTIPLE), again without calling argtype_inherit().
> The only way to reach argtype_inherit() is if there are *no* ancestor
> matches, which means that the function is a very expensive no-op that
> we execute just before throwing an error.
> 
> I'm strongly tempted to just rip out argtype_inherit() and
> gen_cross_product().  Even if we suppose that we might want to resurrect
> the claimed functionality someday, I don't think it could be made to
> work this way.  You'd have to put the knowledge into
> func_select_candidate() instead, else there'd be very weird interactions
> with the heuristics for resolving non-complex input argument types.
> 
> Thoughts?
> 
>             regards, tom lane
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 2: you can get off all lists at once with the unregister command
>     (send "unregister YourEmailAddressHere" to majordomo@postgresql.org)
> 


Re: argtype_inherit() is dead code

From
Tom Lane
Date:
elein@varlena.com (elein) writes:
> Are you saying that the code was supposed "unflatten" the
> arguments of a function into a possible composite type taking into
> consideration the possible inheritance information of the
> composite type?

No, it didn't do that.  AFAICT the case it was supposed to handle
was resolution of ambiguous function calls in what would amount to
an object-oriented-programming usage style.  Consider

create table parent(...);

create table child(...) inherits (parent);

create table grandkid(...) inherits (child);

create function foo(parent) returns ...;

create function foo(child) returns ...;

select foo(t.*) from parent t;        -- uses foo(parent), of course

select foo(t.*) from child t;        -- uses foo(child), of course

select foo(t.*) from grandkid t;    -- ambiguous

Our current code rejects the last with "ambiguous function call",
but an OOP user would expect it to choose foo(child) because that's
the nearer parent supertype.  It looks to me like Postgres once
did choose foo(child), and argtype_inherit() was the code that made
this happen.  It's been broken for a long time though --- at least
since 7.0, because 7.0 rejects this example.

Digging in the CVS history, it appears that I may have broken it here:
http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/parser/parse_coerce.c.diff?r1=2.35;r2=2.36;f=h
It's quite possible that it failed even before that however; I don't
have a pre-7.0 server handy to check it on.  In any case, given the lack
of complaints since 7.0, it doesn't seem anyone is trying to do this
kind of thing.
        regards, tom lane


Re: argtype_inherit() is dead code

From
Alvaro Herrera
Date:
On Sat, Apr 16, 2005 at 03:39:55PM -0400, Tom Lane wrote:

> Digging in the CVS history, it appears that I may have broken it here:
> http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/parser/parse_coerce.c.diff?r1=2.35;r2=2.36;f=h
> It's quite possible that it failed even before that however; I don't
> have a pre-7.0 server handy to check it on.  In any case, given the lack
> of complaints since 7.0, it doesn't seem anyone is trying to do this
> kind of thing.

Given the limitations of table inheritance, it doesn't surprise me that
nobody really uses it to implement object-oriented programs.

Is it really an important area to improve, or are there other priorities?
I know some people wished we had better support for inheritance, but how
strong is that wish?

-- 
Alvaro Herrera (<alvherre[@]dcc.uchile.cl>)
"Para tener más hay que desear menos"


Re: argtype_inherit() is dead code

From
Tom Lane
Date:
Alvaro Herrera <alvherre@dcc.uchile.cl> writes:
> Given the limitations of table inheritance, it doesn't surprise me that
> nobody really uses it to implement object-oriented programs.

True.

> Is it really an important area to improve, or are there other priorities?

There are certainly higher priorities, which is why I'd rather just rip
out the code than try to fix it.
        regards, tom lane


Re: argtype_inherit() is dead code

From
"Joshua D. Drake"
Date:
> Is it really an important area to improve, or are there other 
> priorities? I know some people wished we had better support for 
> inheritance, but how strong is that wish?

Hello,

From a "people who call me" perspective. I am never asked about
inheritance. Most of the people don't even know it is there.
The requests I get are:

Replication (obviously solved)   Multi-Master Replication (working on it ;))
Table Partitioning (No great solution)
IN/OUT Parameteres (being working on)
Good ODBC driver (Soon to be solved)

I get others of course but those are the ones that seem to raise
their head the most.

Sincerely,

Joshua D. Drake





>
>

-- 
Command Prompt, Inc., Your PostgreSQL solutions company. 503-667-4564
Custom programming, 24x7 support, managed services, and hosting
Open Source Authors: plPHP, pgManage, Co-Authors: plPerlNG
Reliable replication, Mammoth Replicator - http://www.commandprompt.com/




Re: argtype_inherit() is dead code

From
Alvaro Herrera
Date:
On Sun, Apr 17, 2005 at 06:56:01AM -0700, Joshua D. Drake wrote:

> From a "people who call me" perspective. I am never asked about
> inheritance. Most of the people don't even know it is there.
> The requests I get are:

Just wondering, does anybody asks you about the excessive locking (and
deadlocking) on foreign keys?  The business about being able to drop
users and then find out they were still owners of something?  I guess I
worry about things too low-level that nobody really cares too much about.

-- 
Alvaro Herrera (<alvherre[@]dcc.uchile.cl>)
"Always assume the user will do much worse than the stupidest thing
you can imagine."                                (Julien PUYDT)


Re: argtype_inherit() is dead code

From
elein@varlena.com (elein)
Date:
As the voice of someone who has a lot of experience with
some of the original inheritance, I would prefer to
have the select foo(t.*) from grandkid work for 
completeness.

However, erroring out as ambiguous is not unreasonable
since we have to cast the hell out of everything usually.
I would suggest putting it on the bug list to fold into
the replacement arguement marshalling code.  That way
we won't (ideally) forget the intended behaviour and
may even fix it at some point.

--elein


On Sat, Apr 16, 2005 at 03:39:55PM -0400, Tom Lane wrote:
> elein@varlena.com (elein) writes:
> > Are you saying that the code was supposed "unflatten" the
> > arguments of a function into a possible composite type taking into
> > consideration the possible inheritance information of the
> > composite type?
> 
> No, it didn't do that.  AFAICT the case it was supposed to handle
> was resolution of ambiguous function calls in what would amount to
> an object-oriented-programming usage style.  Consider
> 
> create table parent(...);
> 
> create table child(...) inherits (parent);
> 
> create table grandkid(...) inherits (child);
> 
> create function foo(parent) returns ...;
> 
> create function foo(child) returns ...;
> 
> select foo(t.*) from parent t;        -- uses foo(parent), of course
> 
> select foo(t.*) from child t;        -- uses foo(child), of course
> 
> select foo(t.*) from grandkid t;    -- ambiguous
> 
> Our current code rejects the last with "ambiguous function call",
> but an OOP user would expect it to choose foo(child) because that's
> the nearer parent supertype.  It looks to me like Postgres once
> did choose foo(child), and argtype_inherit() was the code that made
> this happen.  It's been broken for a long time though --- at least
> since 7.0, because 7.0 rejects this example.
> 
> Digging in the CVS history, it appears that I may have broken it here:
> http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/parser/parse_coerce.c.diff?r1=2.35;r2=2.36;f=h
> It's quite possible that it failed even before that however; I don't
> have a pre-7.0 server handy to check it on.  In any case, given the lack
> of complaints since 7.0, it doesn't seem anyone is trying to do this
> kind of thing.
> 
>             regards, tom lane
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 7: don't forget to increase your free space map settings
> 


Re: argtype_inherit() is dead code

From
"Jim C. Nasby"
Date:
On Sun, Apr 17, 2005 at 06:56:01AM -0700, Joshua D. Drake wrote:
> >Is it really an important area to improve, or are there other 
> >priorities? I know some people wished we had better support for 
> >inheritance, but how strong is that wish?

FWIW, I think people might be more likely to use the OO features that
PostgreSQL already has if there was better OO support in one or more of
the languages. Oracle has some support along these lines and it was nice
being able to make use of it the last time I used Oracle. I don't
remember the exact details, and I don't think they're necessarily the
way you'd want to do it in PostgreSQL anyway, but it was nice being able
to do things like expose a type/class that knew how to pull info from
the database as well as store it there.
-- 
Jim C. Nasby, Database Consultant               decibel@decibel.org 
Give your computer some brain candy! www.distributed.net Team #1828

Windows: "Where do you want to go today?"
Linux: "Where do you want to go tomorrow?"
FreeBSD: "Are you guys coming, or what?"


Re: argtype_inherit() is dead code

From
Rod Taylor
Date:
On Sun, 2005-04-17 at 14:04 -0400, Alvaro Herrera wrote:
> On Sun, Apr 17, 2005 at 06:56:01AM -0700, Joshua D. Drake wrote:
> 
> > From a "people who call me" perspective. I am never asked about
> > inheritance. Most of the people don't even know it is there.
> > The requests I get are:
> 
> Just wondering, does anybody asks you about the excessive locking (and
> deadlocking) on foreign keys?  The business about being able to drop
> users and then find out they were still owners of something?  I guess I
> worry about things too low-level that nobody really cares too much about.

I know of plenty of people impacted by foreign key locking that remove
specific keys in production that they have in place for testing.

-- 



Re: argtype_inherit() is dead code

From
Robert Treat
Date:
On Sunday 17 April 2005 19:30, Rod Taylor wrote:
> On Sun, 2005-04-17 at 14:04 -0400, Alvaro Herrera wrote:
> > On Sun, Apr 17, 2005 at 06:56:01AM -0700, Joshua D. Drake wrote:
> > > From a "people who call me" perspective. I am never asked about
> > > inheritance. Most of the people don't even know it is there.
> > > The requests I get are:
> >
> > Just wondering, does anybody asks you about the excessive locking (and
> > deadlocking) on foreign keys?  The business about being able to drop
> > users and then find out they were still owners of something?  I guess I
> > worry about things too low-level that nobody really cares too much about.
>
> I know of plenty of people impacted by foreign key locking that remove
> specific keys in production that they have in place for testing.
>

That or put calls into try/catch mechanisms "just in case" it deadlocks even 
though it wouldn't with some less restrictive locking mechanism.  Or come up 
with some type of serializing scheme to ensure deadlocks can't happen.  Or 
several other bad schemes.... Alvaro, there are many pints waiting for you 
from a great many postgresql users if you can eliminate this problem with the 
work you're doing on shared row locks. 

-- 
Robert Treat
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL


Re: argtype_inherit() is dead code

From
Rod Taylor
Date:
On Sun, 2005-04-17 at 19:54 -0400, Robert Treat wrote:
> On Sunday 17 April 2005 19:30, Rod Taylor wrote:
> > On Sun, 2005-04-17 at 14:04 -0400, Alvaro Herrera wrote:
> > > On Sun, Apr 17, 2005 at 06:56:01AM -0700, Joshua D. Drake wrote:
> > > > From a "people who call me" perspective. I am never asked about
> > > > inheritance. Most of the people don't even know it is there.
> > > > The requests I get are:
> > >
> > > Just wondering, does anybody asks you about the excessive locking (and
> > > deadlocking) on foreign keys?  The business about being able to drop
> > > users and then find out they were still owners of something?  I guess I
> > > worry about things too low-level that nobody really cares too much about.
> >
> > I know of plenty of people impacted by foreign key locking that remove
> > specific keys in production that they have in place for testing.
> >
> 
> That or put calls into try/catch mechanisms "just in case" it deadlocks even 
> though it wouldn't with some less restrictive locking mechanism.  Or come up 
> with some type of serializing scheme to ensure deadlocks can't happen.  Or 

Deadlocks weren't the issue, insert serialization by the FKey locks was
the issue.

> several other bad schemes.... Alvaro, there are many pints waiting for you 
> from a great many postgresql users if you can eliminate this problem with the 
> work you're doing on shared row locks. 

Agreed.

-- 



Re: argtype_inherit() is dead code

From
Christopher Kings-Lynne
Date:
>>From a "people who call me" perspective. I am never asked about
>>inheritance. Most of the people don't even know it is there.
>>The requests I get are:
> 
> Just wondering, does anybody asks you about the excessive locking (and
> deadlocking) on foreign keys?  The business about being able to drop
> users and then find out they were still owners of something?  I guess I
> worry about things too low-level that nobody really cares too much about.

I get regularly bitten by the former, and have been bitten by the latter 
:)  Don't worry, I think your work is invaluable!

They are subtle problems for people to notice, so they're not as prevalent.

Chris


Re: argtype_inherit() is dead code

From
"Chuck McDevitt"
Date:
Can you tell me more about the good ODBC driver being worked on?
I was thinking of working on this myself, but if someone is already
solving the problem, that's great!


-----Original Message-----
From: pgsql-hackers-owner@postgresql.org
[mailto:pgsql-hackers-owner@postgresql.org] On Behalf Of Joshua D. Drake
Sent: Sunday, April 17, 2005 6:56 AM
To: Alvaro Herrera
Cc: Tom Lane; elein; pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] argtype_inherit() is dead code

> Is it really an important area to improve, or are there other
> priorities? I know some people wished we had better support for
> inheritance, but how strong is that wish?

Hello,

From a "people who call me" perspective. I am never asked about
inheritance. Most of the people don't even know it is there.
The requests I get are:

Replication (obviously solved)   Multi-Master Replication (working on it ;))
Table Partitioning (No great solution)
IN/OUT Parameteres (being working on)
Good ODBC driver (Soon to be solved)

I get others of course but those are the ones that seem to raise
their head the most.

Sincerely,

Joshua D. Drake





>
>

--
Command Prompt, Inc., Your PostgreSQL solutions company. 503-667-4564
Custom programming, 24x7 support, managed services, and hosting
Open Source Authors: plPHP, pgManage, Co-Authors: plPerlNG
Reliable replication, Mammoth Replicator - http://www.commandprompt.com/



---------------------------(end of broadcast)---------------------------
TIP 7: don't forget to increase your free space map settings




Re: argtype_inherit() is dead code

From
Christopher Browne
Date:
The world rejoiced as decibel@decibel.org ("Jim C. Nasby") wrote:
> On Sun, Apr 17, 2005 at 06:56:01AM -0700, Joshua D. Drake wrote:
>> >Is it really an important area to improve, or are there other 
>> >priorities? I know some people wished we had better support for 
>> >inheritance, but how strong is that wish?
>
> FWIW, I think people might be more likely to use the OO features
> that PostgreSQL already has if there was better OO support in one or
> more of the languages. Oracle has some support along these lines and
> it was nice being able to make use of it the last time I used
> Oracle. I don't remember the exact details, and I don't think
> they're necessarily the way you'd want to do it in PostgreSQL
> anyway, but it was nice being able to do things like expose a
> type/class that knew how to pull info from the database as well as
> store it there.

What is there, really, to add?

"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.

The things beyond the essentials are extras that there is great
difficulty in agreeing on.

- Blind fans of the C++ language model think that OO implies certain things;

- Blind fans of the Java language model think that OO implies a different certain set of things;

- Ditto for Smalltalk, Python, and Perl;

- Usually fans of CLOS are pretty open-minded because it is a UNION of a goodly number of object models...
-- 
output = ("cbbrowne" "@" "cbbrowne.com")
http://linuxdatabases.info/info/slony.html
I'm sorry Dave, I can't let you do that.
Why don't you lie down and take a stress pill?


Re: argtype_inherit() is dead code

From
Bruce Momjian
Date:
Alvaro Herrera wrote:
> On Sun, Apr 17, 2005 at 06:56:01AM -0700, Joshua D. Drake wrote:
> 
> > From a "people who call me" perspective. I am never asked about
> > inheritance. Most of the people don't even know it is there.
> > The requests I get are:
> 
> Just wondering, does anybody asks you about the excessive locking (and
> deadlocking) on foreign keys?  The business about being able to drop
> users and then find out they were still owners of something?  I guess I
> worry about things too low-level that nobody really cares too much about.

Those are problems you get into after using PostgreSQL heavily and are
different from front-end questions about missing features.

The beauty of PostgreSQL is the low number of those surprises under
heavy load, but as you mentioned above we have a few of them and have to
get them corrected.

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
359-1001+  If your life is a hard drive,     |  13 Roberts Road +  Christ can be your backup.        |  Newtown Square,
Pennsylvania19073
 


Re: argtype_inherit() is dead code

From
"Joshua D. Drake"
Date:
Alvaro Herrera wrote:
> On Sun, Apr 17, 2005 at 06:56:01AM -0700, Joshua D. Drake wrote:
> 
> 
>>From a "people who call me" perspective. I am never asked about
>>inheritance. Most of the people don't even know it is there.
>>The requests I get are:
> 
> 
> Just wondering, does anybody asks you about the excessive locking (and
> deadlocking) on foreign keys?

I do get the deadlocking on foreign keys question sometimes but there
are ways to directly help that.

  The business about being able to drop
> users and then find out they were still owners of something?

Well remember that we do a lot of the database work for our customers so
we are prepared for some of this ahead of time... and now that I think 
about it that causes my view to be a little skewed.

Sincerely,

Joshua D. Drake


  I guess I
> worry about things too low-level that nobody really cares too much about.
> 


-- 
Your PostgreSQL solutions company - Command Prompt, Inc. 1.800.492.2240
PostgreSQL Replication, Consulting, Custom Programming, 24x7 support
Managed Services, Shared and Dedication Hosting
Co-Authors: plPHP, plPerlNG - http://www.commandprompt.com/


Re: argtype_inherit() is dead code

From
"Jim C. Nasby"
Date:
On Sun, Apr 17, 2005 at 07:01:41PM -0400, Christopher Browne wrote:
> The world rejoiced as decibel@decibel.org ("Jim C. Nasby") wrote:
> > On Sun, Apr 17, 2005 at 06:56:01AM -0700, Joshua D. Drake wrote:
> >> >Is it really an important area to improve, or are there other 
> >> >priorities? I know some people wished we had better support for 
> >> >inheritance, but how strong is that wish?
> >
> > FWIW, I think people might be more likely to use the OO features
> > that PostgreSQL already has if there was better OO support in one or
> > more of the languages. Oracle has some support along these lines and
> > it was nice being able to make use of it the last time I used
> > Oracle. I don't remember the exact details, and I don't think
> > they're necessarily the way you'd want to do it in PostgreSQL
> > anyway, but it was nice being able to do things like expose a
> > type/class that knew how to pull info from the database as well as
> > store it there.
> 
> What is there, really, to add?
> 
> "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.

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

An object should be able to have methods attached to it, for example.
And that functionality is essentially missing. There's no way to present
a combined set data and code that operates on that data.

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.

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.
-- 
Jim C. Nasby, Database Consultant               decibel@decibel.org 
Give your computer some brain candy! www.distributed.net Team #1828

Windows: "Where do you want to go today?"
Linux: "Where do you want to go tomorrow?"
FreeBSD: "Are you guys coming, or what?"


Re: argtype_inherit() is dead code

From
"Dave Held"
Date:
> -----Original Message-----
> From: Jim C. Nasby [mailto:decibel@decibel.org]
> 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