argtype_inherit() is dead code

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

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(at)postgresql(dot)org)
>

elein(at)varlena(dot)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

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[(at)]dcc(dot)uchile(dot)cl>)
"Para tener más hay que desear menos"

Alvaro Herrera <alvherre(at)dcc(dot)uchile(dot)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

> 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/

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[(at)]dcc(dot)uchile(dot)cl>)
"Always assume the user will do much worse than the stupidest thing
you can imagine." (Julien PUYDT)

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(at)varlena(dot)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
>

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(at)decibel(dot)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?"

The world rejoiced as decibel(at)decibel(dot)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?

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.

--

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

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.

--

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

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(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

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/

On Sun, Apr 17, 2005 at 07:01:41PM -0400, Christopher Browne wrote:
> The world rejoiced as decibel(at)decibel(dot)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(at)decibel(dot)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?"