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
>