pá 26. 7. 2019 v 22:53 odesílatel Tom Lane <tgl@sss.pgh.pa.us> napsal:
I wrote: > 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.
After thinking about this a bit more, it seems like you could avoid a lot of problems if you restricted what the support function call does to be potentially replacing the result type of a function declared to return ANY with some more-specific type (computed from examination of the actual arguments). That would make it act much more like a traditional polymorphic function. It'd remove the issues about interactions among multiple potentially-matching functions, since we'd only call a single support function for an already-identified target function.
I am not sure if I understand well - so I repeat it with my words.
So calculation of result type (replace ANY by some specific) can be ok?
I am able to do it if there will be a agreement.
I wrote a possibility to specify argument types as optimization as protection against repeated type identification and casting (that can be done in planning time, and should not be repeated).
This feature should be used only for functions with types fx("any", "any", ..) returns "any". So it is very probable so in execution type you should to do some work with parameter type identification.
But if we find a agreement just on work with return type, then it is good enough solution. The practical overhead of type cache inside function should not be dramatic.
You'd still need to touch everyplace that knows about polymorphic type resolution, since this would essentially be another form of polymorphic function. And I'm still very dubious that it's worth the trouble. But it would be a lot more controllable than the proposal as it stands.
