Re: Domains as Subtypes

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: elein <elein(at)varlena(dot)com>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Domains as Subtypes
Date: 2006-03-24 20:47:13
Message-ID: 9075.1143233233@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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?

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2006-03-24 20:56:39 Re: Role incompatibilities
Previous Message Stephen Frost 2006-03-24 19:56:06 Re: Role incompatibilities