Re: Domain breakage - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Domain breakage
Date
Msg-id 21892.1053909321@sss.pgh.pa.us
Whole thread Raw
In response to Domain breakage  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Awhile back I said:
> Here's a fun one: in 7.3 or CVS tip, try
> regression=# create domain tint as int;
> CREATE DOMAIN
> regression=# select  1::tint > (-1);
>  ?column?
> ----------
>  t
> (1 row)

> regression=# select  1::tint > (-1)::tint;
>  ?column?
> ----------
>  f
> (1 row)

> How's that again?  Well, when you dig into it you find that the second
> case is invoking the OID greater-than operator (oidgt), which does
> unsigned comparison.

> I suspect that the most workable fix for this is to reduce all the input
> typeids to base types before we start the operator or function type
> resolution routines.  However, this would completely destroy any hope of
> making domain-specific operators.

I have repaired this problem by doing the above.  It turns out that this
does not completely foreclose building domain-specific operators: the
check for exact-match operators is done beforehand, so you can use a
domain-specific operator as long as it's an exact match to the input
datatypes.  But as soon as there's not an exact match, operators on the
base type will be preferred.  This seems a workable compromise to me.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: array functions - request for opinions (was Re: [PATCHES] array
Next
From: Tom Lane
Date:
Subject: Re: vacuum analyze corrupts database