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
