Re: Domains as Subtypes - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Domains as Subtypes
Date
Msg-id 9075.1143233233@sss.pgh.pa.us
Whole thread Raw
In response to Domains as Subtypes  (elein <elein@varlena.com>)
Responses Re: Domains as Subtypes  (elein <elein@varlena.com>)
List pgsql-hackers
elein <elein@varlena.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?

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.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Stephen Frost
Date:
Subject: Re: Role incompatibilities
Next
From: Tom Lane
Date:
Subject: Re: Role incompatibilities