pá 26. 7. 2019 v 22:03 odesílatel Tom Lane <t...@sss.pgh.pa.us> napsal:
> Pavel Stehule <pavel.steh...@gmail.com> writes:
> > so 9. 3. 2019 v 7:22 odesílatel Pavel Stehule <pavel.steh...@gmail.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.
>
I quietly expect so this feature will be used without combination with
overloading. But the combination of support function and overloading can be
explicitly disabled - (in runtime for simple implementation).
> 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?
>
There are two cases of usage
a) combination of polymorphic types - fx(t1, t1, t2, t1, t2, t1, t2, ...)
b) forcing types fx(t1, t2) t1 force explicit cast for t2 to t1
c) optimization of repeated call of functions like fx("any", "any", "any",
...)
It is pretty hard to create simple non-procedural language to describe
syntaxes like @a. But with procedural code it is easy.
@c is special case, that we can do already. But we cannot to push casting
outside function, and inside function, there is a overhead with casting.
With implementing type case inside function, then we increase startup time
and it is overhead for function started by plpgsql runtime.
> 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.)
>
The helper function should be immutable - what I know, is not possible to
change data types dynamically, so repeated call should not be effective,
but should to produce same result, so it should not be a problem.
>
> 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 this case it is decision, because I don't expect overloading.
I understand to your objections about mixing parser helper functions and
overloading. Currently it is pretty hard to understand what will be
expected behave when somebody overload function with polymorphic function.
With parser helper function the overloading is not necessary and can be
disabled.
> In short, I think the added complexity and bug potential outweigh
> any possible gain from this.
>
> regards, tom lane
>
