On Sat, Jul 27, 2019 at 5:45 PM Pavel Stehule <pavel.steh...@gmail.com> wrote: > pá 26. 7. 2019 v 22:53 odesílatel Tom Lane <t...@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. ...
Hi Pavel, I see that this is an active project with an ongoing discussion, but we have run out of July so I have moved this to the September CF and set it to "Waiting on Author". -- Thomas Munro https://enterprisedb.com
