Re: proposal: type info support functions for functions that use "any" type

Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> writes:
> so 9. 3. 2019 v 7:22 odesílatel Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
> napsal:
>> Tom introduced supported functions for calculation function's selectivity.
>> Still I have similar idea to use supported function for calculation
>> function's parameter's types and function return type.
>> Motivation:
>> Reduce a necessity of overloading of functions. My motivation is related
>> primary to Orafce, but this feature should be helpful for anybody with
>> similar goals. The function's overloading is great functionality but it is
>> hard for maintenance.

> here is a patch

TBH, I don't like this proposal one bit. As far as I can see, the idea
is to let a function's support function redefine the function's declared
argument and result types on-the-fly according to no predetermined rules,
and that seems to me like it's a recipe for disaster. How will anyone
understand which function(s) are candidates to match a query, or why one
particular candidate got selected over others? It's already hard enough
to understand the behavior of polymorphic functions in complex cases,
and those are much more constrained than this would be.

Moreover, I don't think you've even provided a compelling example
case. What's this doing that you couldn't do with existing polymorphic
types or the anycompatibletype proposal?

I also strongly suspect that this would break pieces of the system
that expect that the stored pg_proc.prorettype has something to do
with reality. At minimum, you'd need to fix a number of places you
haven't touched here that have their own knowledge of function type
resolution, such as enforce_generic_type_consistency,
resolve_polymorphic_argtypes, resolve_aggregate_transtype. Probably
anyplace that treats polymorphics as being any sort of special case
would have to be taught to re-call the support function to find out
what it should think the relevant types are.

(I don't even want to think about what happens if the support function's
behavior changes between original parsing and these re-checking spots.)

Another thing that's very much less than compelling about your example
is that your support function seems to be happy to throw errors
if the argument types don't match what it's expecting. That seems
quite unacceptable, since it would prevent the parser from moving on
to consider other possibly-matching functions. Maybe that's just
because it's a quick hack not a polished example, but it doesn't
seem like a good precedent.

In short, I think the added complexity and bug potential outweigh
any possible gain from this.

regards, tom lane