Re: Unknown-type resolution rules, redux

Added to TODO.detail.

> parse_coerce.c contains the following conversation --- I believe the
> first XXX comment is from me and the second from you:
>
> /*
> * Still too many candidates? Try assigning types for the unknown
> * columns.
> *
> * We do this by examining each unknown argument position to see if all
> * the candidates agree on the type category of that slot. If so, and
> * if some candidates accept the preferred type in that category,
> * eliminate the candidates with other input types. If we are down to
> * one candidate at the end, we win.
> *
> * XXX It's kinda bogus to do this left-to-right, isn't it? If we
> * eliminate some candidates because they are non-preferred at the
> * first slot, we won't notice that they didn't have the same type
> * category for a later slot.
> * XXX Hmm. How else would you do this? These candidates are here because
> * they all have the same number of matches on arguments with explicit
> * types, so from here on left-to-right resolution is as good as any.
> * Need a counterexample to see otherwise...
> */
>
> The comment is out of date anyway because it fails to mention the new
> rule about preferring STRING category. But to answer your request for
> a counterexample: consider
>
> SELECT foo('bar', 'baz')
>
> First, suppose the available candidates are
>
> foo(float8, int4)
> foo(float8, point)
>
> In this case, we examine the first argument position, see that all the
> candidates agree on NUMERIC category, so we consider resolving the first
> unknown input to float8. That eliminates neither candidate so we move
> on to the second argument position. Here there is a conflict of
> categories so we can't eliminate anything, and we decide the call is
> ambiguous. That's correct (or at least Operating As Designed ;-)).
>
> But now suppose we have
>
> foo(float8, int4)
> foo(float4, point)
>
> Here, at the first position we will still see that all candidates agree
> on NUMERIC category, and then we will eliminate candidate 2 because it
> isn't the preferred type in that category. Now when we come to the
> second argument position, there's only one candidate left so there's
> no category conflict. Result: this call is considered non-ambiguous.
>
> This means there is a left-to-right bias in the algorithm. For example,
> the exact same call *would* be considered ambiguous if the candidates'
> argument orders were reversed:
>
> foo(int4, float8)
> foo(point, float4)
>
> I do not like that. You could maybe argue that earlier arguments are
> more important than later ones for functions, but it's harder to make
> that case for binary operators --- and in any case this behavior is
> extremely difficult to explain in prose.
>
> To fix this, I think we need to split the loop into two passes.
> The first pass does *not* remove any candidates. What it does is to
> look separately at each UNKNOWN-argument position and attempt to deduce
> a probable category for it, using the following rules:
>
> * If any candidate has an input type of STRING category, use STRING
> category; else if all candidates agree on the category, use that
> category; else fail because no resolution can be made.
>
> * The first pass must also remember whether any candidates are of a
> preferred type within the selected category.
>
> The probable categories and exists-preferred-type booleans are saved in
> local arrays. (Note this has to be done this way because
> IsPreferredType currently allows more than one type to be considered
> preferred in a category ... so the first pass cannot try to determine a
> unique type, only a category.)
>
> If we find a category for every UNKNOWN arg, then we enter a second loop
> in which we discard candidates. In this pass we discard a candidate if
> (a) it is of the wrong category, or (b) it is of the right category but
> is not of preferred type in that category, *and* we found candidate(s)
> of preferred type at this slot.
>
> If we end with exactly one candidate then we win.
>
> It is clear in this algorithm that there is no order dependency: the
> conditions for keeping or discarding a candidate are fixed before we
> start the second pass, and do not vary depending on which other
> candidates were discarded before it.
>
> Comments?
>
> regards, tom lane
>

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026