Re: argtype_inherit() is dead code
От | Tom Lane |
---|---|
Тема | Re: argtype_inherit() is dead code |
Дата | |
Msg-id | 21045.1113680395@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: argtype_inherit() is dead code (elein@varlena.com (elein)) |
Ответы |
Re: argtype_inherit() is dead code
Re: argtype_inherit() is dead code |
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: