Skip site navigation (1) Skip section navigation (2)

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 (view raw or flat)
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

pgsql-hackers by date

Next:From: Tom LaneDate: 2006-03-24 20:56:39
Subject: Re: Role incompatibilities
Previous:From: Stephen FrostDate: 2006-03-24 19:56:06
Subject: Re: Role incompatibilities

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group