Re: Domains as Subtypes

On Fri, Mar 24, 2006 at 03:47:13PM -0500, Tom Lane wrote:
> elein <elein(at)varlena(dot)com> writes:
> > Attached is a patch to parse_oper.c which essentially does the
> > following. The major change is in binary_oper_exact().
> > Instead of checking only one level of the basetype it checks
> > all possible combinations of type and parent types for
> > an exact match (only).
>
> I'm going to object to this just on the grounds of the extent to which
> it will slow down parsing. I also think it completely destroys the
> logical structure of the lookup code: binary_operator_exact is supposed
> to find exact matches, nothing else. Approximate matches should be
> sought only after that's failed. Also, why aren't the unary-operator
> cases handled? And why are you making the semantics of operator lookup
> different from function lookup?

I chose to mess with binary_exact_oper() primarily because this is where
you put in domain checking. I was following the logical structure that was there.

Also, prior to my patch, it reset the argument types causing the func sel check
to choose the wrong function. Without at least part of my change, arguments
to an operator which have two different types as operands do not get
kicked out to func sel properly (with the type id set to unknown id).

Operators have the single distinction from functions in that when one argument
has an unknown type, then an exact match is tried with the unknown arg
type set to the known type. This code has always been in there. I believe
it was introduced to catch most cases before having to go through func sel check.
My code does expand it to do parent type checking, though.

>
> The correct place to be fooling with this is in func_select_candidate(),
> whose initial smashing of domains to base types is the proximate cause
> of the problems you are complaining of. I think what you'd need is to
> get rid of that blunt instrument and instead put in some kind of logic
> to prefer matches to "higher up" domains over matches to the base type,
> while not entirely excluding the latter. func_select_candidate()
> already has a lot of heuristics about preferring some matches over
> others, and should be able to deal with one more.

I think it was binary_oper_exact which smashed the types into basetypes.
Perhaps both did. I can look into moving the type hierarchy arg checking over
to func_select if you are sure this is the way to go.

>
> regards, tom lane
>
> ---------------------------(end of broadcast)---------------------------
> TIP 9: In versions below 8.0, the planner will ignore your desire to
> choose an index scan if your joining column's datatypes do not
> match
>
elein
elein(at)varlena(dot)com