Received: from renoir.op.net (root@renoir.op.net [207.29.195.4])

by candle.pha.pa.us (8.9.0/8.9.0) with ESMTP id RAA05808

for <pgman@candle.pha.pa.us>; Sun, 14 May 2000 17:30:52 -0400 (EDT)

Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2]) by renoir.op.net (o1/$Revision: 1.2 $) with ESMTP id RAA16657 for <pgman@candle.pha.pa.us>; Sun, 14 May 2000 17:29:52 -0400 (EDT)

Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2]) by renoir.op.net (o1/$Revision: 1.3 $) with ESMTP id RAA16657 for <pgman@candle.pha.pa.us>; Sun, 14 May 2000 17:29:52 -0400 (EDT)

Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])

by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id RAA20914;

Sun, 14 May 2000 17:29:30 -0400 (EDT)

regards, tom lane

From pgsql-hackers-owner+M1936@postgresql.org Sun Dec 10 13:17:54 2000

Received: from mail.postgresql.org (webmail.postgresql.org [216.126.85.28])

by candle.pha.pa.us (8.9.0/8.9.0) with ESMTP id NAA20676

for <pgman@candle.pha.pa.us>; Sun, 10 Dec 2000 13:17:54 -0500 (EST)

Received: from mail.postgresql.org (webmail.postgresql.org [216.126.85.28])

by mail.postgresql.org (8.11.1/8.11.1) with SMTP id eBAIGvZ40566;

Sun, 10 Dec 2000 13:16:57 -0500 (EST)

(envelope-from pgsql-hackers-owner+M1936@postgresql.org)

Received: from sss.pgh.pa.us (sss.pgh.pa.us [209.114.132.154])

by mail.postgresql.org (8.11.1/8.11.1) with ESMTP id eBAI8HZ39820

for <pgsql-hackers@postgreSQL.org>; Sun, 10 Dec 2000 13:08:17 -0500 (EST)

(envelope-from tgl@sss.pgh.pa.us)

Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])

by sss.pgh.pa.us (8.11.1/8.11.1) with ESMTP id eBAI82o28682;

Sun, 10 Dec 2000 13:08:02 -0500 (EST)

To: Thomas Lockhart <lockhart@alumni.caltech.edu>

cc: pgsql-hackers@postgresql.org

Subject: [HACKERS] Unknown-type resolution rules, redux

Date: Sun, 10 Dec 2000 13:08:02 -0500

Message-ID: <28679.976471682@sss.pgh.pa.us>

From: Tom Lane <tgl@sss.pgh.pa.us>

Precedence: bulk

Sender: pgsql-hackers-owner@postgresql.org

Status: OR

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