Re: polymorphic parameters limits - correct solution?
| От | Pavel Stehule |
|---|---|
| Тема | Re: polymorphic parameters limits - correct solution? |
| Дата | |
| Msg-id | CAFj8pRDU3gEHcHXCUkOmc3Si3-1OFVMXY+gpyFem_XsLbZ+yUg@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: polymorphic parameters limits - correct solution? (Alvaro Herrera <alvherre@alvh.no-ip.org>) |
| Список | pgsql-hackers |
2018-01-16 3:21 GMT+01:00 Alvaro Herrera <alvherre@alvh.no-ip.org>:
Pavel Stehule wrote:
> Hi
>
> I played with introduction of new pair of Polymorphic Parameters - like
> anyXelement and anyXarray. Now, I don't think so enhancing PP is good way
> now. Without significant redesign there are not practical append more code
> there.
>
> Why this is a issue? The extension's authors are not able to specify result
> type without enumeration of all possible function signatures. Similar
> situation is in argument processing - there are workaround based on "any"
> type.
I cannot offer any advice for your "helper" (because I don't really
understand what the helper does), but I am reminded of this old thread:
https://www.postgresql.org/message-id/flat/ 20090908161210.GD549%40alvh. no-ip.org
yes - it is same issue. There are possible two ways
1. with polymorphic types
2. with some aux functions that dynamically generate current function's signature - used in core (coalesce, greather, ...)
@1 is difficult when you can implement different strategies about work with arguments
a) depends on first
b) depends on common type
c) depends on second
So I am thinking so the best possibility is allow same functionality that we use in core to extension authors.
Regards
Pavel
... in which datatype "any" was one of the offered tools, and also from
whence the format() function sprung. Nice ...
--
Álvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
В списке pgsql-hackers по дате отправления: