From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Jeff Davis <pgsql(at)j-davis(dot)com> |
Cc: | Heikki Linnakangas <heikki(at)enterprisedb(dot)com>, pgsql-hackers(at)postgreSQL(dot)org |
Subject: | Re: declarations of range-vs-element <@ and @> |
Date: | 2011-11-17 20:50:20 |
Message-ID: | 5161.1321563020@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Jeff Davis <pgsql(at)j-davis(dot)com> writes:
> On Wed, 2011-11-16 at 16:41 -0500, Tom Lane wrote:
>> I propose adding a step to func_select_candidate
>> that tries to resolve things that way, ie, if all the known-type inputs
>> have the same type, then try assuming that the unknown-type ones are of
>> that type, and see if that leads to a unique match. There actually is a
>> comment in there that claims we do that, but the code it's attached to
>> is really doing something else that involves preferred types within
>> type categories...
>>
>> Thoughts?
> That sounds reasonable to me.
Here's a draft patch (sans doc changes as yet) that extends the
ambiguous-function resolution rules that way. It adds the heuristic at
the very end, at the point where we would otherwise fail, and therefore
it cannot change the system's behavior for any case that didn't
previously draw an "ambiguous function/operator" error. I experimented
with placing the heuristic earlier in func_select_candidate, but found
that that caused some changes in regression test cases, which made me a
bit nervous. Those changes were not clearly worse results, but this
isn't an area that I think we should toy with lightly.
I haven't yet tried again on changing the <@ and @> declarations, but
will do that next.
regards, tom lane
Attachment | Content-Type | Size |
---|---|---|
resolve-unknowns.patch | text/x-patch | 7.5 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2011-11-17 20:51:06 | RangeVarGetRelid() |
Previous Message | Peter Eisentraut | 2011-11-17 20:18:49 | Re: Core Extensions relocation |