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.
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.
regards, tom lane
