On Sat, Jul 27, 2019 at 5:45 PM Pavel Stehule <pavel.stehule@gmail.com> wrote:
> 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.
...
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
