Re: proposal: type info support functions for functions that use "any" type

pá 26. 7. 2019 v 22:53 odesílatel Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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.

I wrote a possibility to specify argument types as optimization as
protection against repeated type identification and casting (that can be
done in planning time, and should not be repeated).

This feature should be used only for functions with types fx("any", "any",
..) returns "any". So it is very probable so in execution type you should
to do some work with parameter type identification.

But if we find a agreement just on work with return type, then it is good
enough solution. The practical overhead of type cache inside function
should not be dramatic.

> 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.
>

ok

> regards, tom lane
>