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

Hi

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

Regards

Pavel

> regards, tom lane
>