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

Hi

út 14. 1. 2020 v 22:09 odesílatel Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> napsal:

> Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> writes:
> > [ parser-support-function-with-demo-20191128.patch ]
>
> TBH, I'm still not convinced that this is a good idea. Restricting
> the support function to only change the function's return type is
> safer than the original proposal, but it's still not terribly safe.
> If you change the support function's algorithm in any way, how do
> you know whether you've broken existing stored queries? If the
> support function consults external resources to make its choice
> (perhaps checking the existence of a cast), where could we record
> that the query depends on the existence of that cast? There'd be
> no visible trace of that in the query parsetree.
>
>
I reread all related mails and I think so it should be safe - or there is
same risk like using any C extensions for functions or hooks.

I use a example from demo

+CREATE FUNCTION decode_support(internal)
+RETURNS internal
+AS 'MODULE_PATHNAME'
+LANGUAGE C IMMUTABLE STRICT PARALLEL SAFE;
+
+--
+-- decode function - example of function that returns "any" type
+--
+CREATE FUNCTION decode(variadic "any")
+RETURNS "any"
+AS 'MODULE_PATHNAME'
+LANGUAGE C IMMUTABLE STRICT PARALLEL SAFE SUPPORT decode_support;

The support function (and implementation) is joined with "decode" function.
So I cannot to change the behave of support function without reloading a
extension, and it needs typically session reconnect.

> I'm also still not convinced that this idea allows doing anything
> that can't be done just as well with polymorphism. It would be a
> really bad idea for the support function to be examining the values
> of the arguments (else what happens when they're not constants?).
> So all you can do is look at their types, and then it seems like
> the things you can usefully do are pretty much like polymorphism,
> i.e. select some one of the input types, or a related type such
> as an array type or element type. If there are gaps in what you
> can express with polymorphism, I'd much rather spend effort on
> improving that facility than in adding something that is only
> accessible to advanced C coders. (Yes, I know I've been slacking
> on reviewing [1].)
>

The design is based not on values, just on types. I don't need to know a
value, I need to know a type.

Currently our polymorphism is not enough - and is necessary to use "any"
datatype. This patch just add a possibility to use "any" as return type.

I spent on this topic lot of time and one result is patch [1]. This patch
increase situation lot of, but cannot to cover all. There are strong limits
for variadic usage.

This patch is really not about values, it is about types - and about more
possibility (and more elasticity) to control result type.

> Lastly, I still think that this patch doesn't begin to address
> all the places that would have to know about the feature. There's
> a lot of places that know about polymorphism --- if this is
> polymorphism on steroids, which it is, then why don't all of those
> places need to be touched?
>

It is working with "any" type, and then it can be very small, because the
all work with this type is moved to extension.

> On the whole I think we should reject this idea.
>

I will accept any your opinion. Please, try to understand to me as Orafce
developer, maintainer. I would to clean this extension, and current state
of polymorphism (with patch [1]) doesn't allow it.

I am open to any proposals, ideas.

Regards

Pavel

> regards, tom lane
>
> [1] https://commitfest.postgresql.org/26/1911/
>