Re: polymorphic types - enforce casting to most common type automatically

2015-07-10 23:19 GMT+02:00 Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>:

> Hi
>
> 2015-07-10 18:43 GMT+02:00 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:
>
>> Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> writes:
>> > now a functions with more than one polymorphic arguments are relative
>> > fragile due missing casting to most common type. Some our "functions"
>> like
>> > "coalesce" can do it, so it is surprising for our users.
>>
>> > our custom polymorphic function foo(anyelement, anyelement) working
>> well for
>> > foo(10,20) or foo(10.1, 20.1), but not for foo(10, 20.1)
>>
>> > I am thinking, so we can add a searching most common type stage without
>> > breaking to backing compatibility.
>>
>> > What do you think about it?
>>
>> I see nobody's replied to this, still, so ...
>>
>> I think this is simply a bad idea, for a couple of reasons:
>>
>> 1. It will reduce predictability of type resolution.
>>
>
> I don't think - same mechanism we use - it doesn't introduce some new.
>
>
>>
>> 2. It will greatly increase the risk of getting "ambiguous function call"
>> failures, because of adding more possible ways to match the same call.
>> (The argument that we'd not break backwards compatibility is thus bogus.)
>>
>
> Maybe I not described well my idea.
>
> This can generate new conflicts only when new behave will be different
> than old behave. And different old behave is not possible - it fails on
> error now. So there is possible, with this patch, some queries can fail on
> conflict, but this code fails on "function doesn't exists" now. So if there
> is some possibility of breaking compatibility, then one error can be
> replaced by different error. It is known best practice to don't mix
> polymorphic parameters and function overloading.
>
> Why I need it - the motivation, why I returned to this topic is issue
> https://github.com/orafce/orafce/issues/17 and some questions about same
> topic on stackoverflow.
>
> There is workaround with "any" type - but I have to repeat lot of work
> what core analyzer can do, and the code in extension is longer. And I have
> to write extension in C.
>

It worse - workaround with "any" isn't good enough for implementation NVL
function - because I cannot to change result type inside function.

I know, so you dislike parser/analyzer hook, but is there any other
possibility? Some hint in pg_class?

Regards

Pavel

>
>
>>
>> Worth noting for onlookers is that the submitted patch seems to be using
>> UNION-style rules to determine a common type for anyelement arguments,
>> not just counting the "most common" type among the arguments as you might
>> think from the subject. But that doesn't make things any better.
>>
>
> it is related to only polymorphic types.
>
>>
>> An example of what would presumably happen if we adopted this sort of rule
>> (I've not checked whether the patch as written does this, but it would
>> logically follow) is that appending a float to an integer array would
>> cause the whole array to be silently promoted to float, with attendant
>> possible loss of precision for existing array elements.
>
>
> it is based on select_common_type() - so it is use only available implicit
> casts.
>
>
>> That does not
>> seem to me to satisfy the principle of least astonishment. Related,
>> even more astonishing behaviors could ensue from type promotion in
>> anyrange situations, eg range_contains_elem(anyrange,anyelement).
>> So I think it's just as well that we make people write a cast to show
>> what they mean in such cases.
>>
>
> The polymorphic parameters create much bigger space - if somebody needs to
> less variability, then he doesn't use polymorphic params.
>
> I understand to some situation, when we prefer strict work with
> polymorphic parameters - theoretically we can introduce new option that
> enforce it.
>
>
>> In fact, if you discount cases involving anyarray and anyrange, we do not
>> have *any* built-in functions for which this patch would do anything,
>> except for the three-argument forms of lead() and lag(), where I think it
>> would be rather astonishing to let the default-value argument control the
>> result type, anyway. This leaves me feeling dubious both about the actual
>> scope of the use-case for such a change, and about whether "use the UNION
>> rules" would be a sensible heuristic even if we wanted to do something.
>> There seem to be too many cases where it's not a great idea to put all the
>> arguments on exactly equal footing for deciding what common type to
>> choose.
>>
>
> Very common problem of polymorphic parameters is mix of numeric and
> integers as parameters. It is one known gotcha - and I am trying to solve
> it.
>
> Regards
>
> Pavel
>
>
>>
>> So I'm inclined to mark this patch as Rejected.
>>
>> regards, tom lane
>>
>
>