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.
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.
I am sending reduced version of previous patch. Now, support function is used just for replacement of returned type "any" by some other.
The are two patches - shorter with only support function, larger with demo "decode" function. I don't expect so the "decode" extension should be pushed to master. It is just demo of usage.
