Thread

1. declarations of range-vs-element <@ and @>

   Tom Lane <tgl@sss.pgh.pa.us> — 2011-11-16T17:24:02Z

   Why do these use anynonarray rather than anyelement?  Given that we
   support ranges of arrays (there's even a regression test), this seems
   a bogus limitation.
   
   			regards, tom lane
   
   

2. Re: declarations of range-vs-element <@ and @>

   Tom Lane <tgl@sss.pgh.pa.us> — 2011-11-16T21:41:11Z

   I wrote:
   > Why do these use anynonarray rather than anyelement?  Given that we
   > support ranges of arrays (there's even a regression test), this seems
   > a bogus limitation.
   
   After experimenting with changing that, I see why you did it: some of
   the regression tests fail, eg,
   
     SELECT * FROM array_index_op_test WHERE i <@ '{38,34,32,89}' ORDER BY seqno;
     ERROR:  operator is not unique: integer[] <@ unknown
   
   That is, if we have both anyarray <@ anyarray and anyelement <@ anyrange
   operators, the parser is unable to decide which one is a better match to
   integer[] <@ unknown.  However, restricting <@ to not work for ranges
   over arrays is a pretty horrid fix for that, because there is simply not
   any access to the lost functionality.  It'd be better IMO to fail here
   and require the unknown literal to be cast explicitly than to do this.
   
   But what surprises me about this example is that I'd have expected the
   heuristic "assume the unknown is of the same type as the other input"
   to resolve it.  Looking more closely, I see that we apply that heuristic
   in such a way that it works only for exact operator matches, not for
   matches requiring coercion (including polymorphic-type matches).  This
   seems a bit weird.  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?
   
   			regards, tom lane
   
   

3. Re: declarations of range-vs-element <@ and @>

   Jeff Davis <pgsql@j-davis.com> — 2011-11-17T18:18:47Z

   On Wed, 2011-11-16 at 16:41 -0500, Tom Lane wrote:
   > But what surprises me about this example is that I'd have expected the
   > heuristic "assume the unknown is of the same type as the other input"
   > to resolve it.  Looking more closely, I see that we apply that heuristic
   > in such a way that it works only for exact operator matches, not for
   > matches requiring coercion (including polymorphic-type matches).  This
   > seems a bit weird.  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.
   
   Regards,
   	Jeff Davis
   
   
   

4. Re: declarations of range-vs-element <@ and @>

   Tom Lane <tgl@sss.pgh.pa.us> — 2011-11-17T20:50:20Z

   Jeff Davis <pgsql@j-davis.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