Re: Domains and type coercion

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Thomas Lockhart <lockhart(at)fourpalms(dot)org>
Cc: pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: Domains and type coercion
Date: 2002-03-20 20:24:52
Message-ID: 7007.1016655892@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

I wrote:
> I am thinking that a non-broken approach would involve (1) treating
> a domain as binary-compatible with its base type, and therefore with
> all other domains on the same base type, and (2) allowing a coercion
> function that produces the base type to be used to produce the domain
> type.

I've committed code that does this, and it seems to handle the basic
cases okay. However, there are still some corner cases that are
unfriendly:

regression=# create domain mydom as numeric(7,2);
CREATE DOMAIN
regression=# create table foo (f1 numeric(7,2), f2 mydom);
CREATE
regression=# insert into foo values(111,222);
INSERT 139780 1
regression=# select f1 + 42 from foo;
?column?
----------
153.00
(1 row)

regression=# select f2 + 42 from foo;
ERROR: Unable to identify an operator '+' for types 'mydom' and 'integer'
You will have to retype this query using an explicit cast

The problem seems to be that when parse_func looks for "exact match"
operators, it doesn't consider numeric to be an exact match for mydom.
So that heuristic fails and we're left with no unique best choice for
the operator.

I'm not sure if there's anything much that can be done about this.
We could treat exact and binary-compatible matches alike (doesn't seem
good), or put a special case into the operator selection rules to reduce
domains to their basetypes before making the "exact match" test.
Neither of these seem real appealing, but if we don't do something
I think that domains are going to be a big pain in the neck to use.

Any thoughts?

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2002-03-20 20:25:13 Re: [HACKERS] Fixes gram.y
Previous Message Tom Lane 2002-03-20 20:08:53 Re: Domain Support -- another round