Обсуждение: polymorphic parameters limits - correct solution?
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.
Can we design helper function used only for function that returns "any" type, that returns correct result type?
some like
CREATE OR REPLACE FUNCTION fx("any", "any")
RETURNS "any" AS ...
CREATE OR REPLACE FUNCTION fx_helper(Oid[])
RETURNS Oid AS ..
ALTER FUNCTION fx("any", "any") SET ('result_helper', 'fx_helper'::regproc);
possibly, there can be some argument helper, that can specify UNKNOWN arguments.
Notes, comments?
Regards
Pavel
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 ... 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
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