čt 1. 8. 2019 v 11:01 odesílatel Thomas Munro <thomas.mu...@gmail.com> napsal:
> 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". > sure Pavel > -- > Thomas Munro > https://enterprisedb.com >
