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

Поиск
Список
Период
Сортировка
От Pavel Stehule
Тема Re: proposal: type info support functions for functions that use"any" type
Дата
Msg-id CAFj8pRDhtgbc4M=H0iw9HC36oRxm4BR67R3YcKpeDs7Zd2W3ww@mail.gmail.com
обсуждение исходный текст
Ответ на Re: proposal: type info support functions for functions that use "any" type  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: proposal: type info support functions for functions that use"any" type  (Thomas Munro <thomas.munro@gmail.com>)
Список pgsql-hackers


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.

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

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Pavel Stehule
Дата:
Сообщение: Re: proposal: type info support functions for functions that use"any" type
Следующее
От: Amit Kapila
Дата:
Сообщение: Re: SegFault on 9.6.14