Re: Domains and type coercion
От | Tom Lane |
---|---|
Тема | Re: Domains and type coercion |
Дата | |
Msg-id | 7007.1016655892@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Domains and type coercion (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | 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 usingan 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
В списке pgsql-hackers по дате отправления: