| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | "Jim C(dot) Nasby" <decibel(at)decibel(dot)org> |
| Cc: | pgsql-general(at)postgresql(dot)org |
| Subject: | Re: Casting from a domain |
| Date: | 2005-03-04 20:40:17 |
| Message-ID: | 10873.1109968817@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
"Jim C. Nasby" <decibel(at)decibel(dot)org> writes:
> decibel=# create cast (interval as rrs.seconds) WITH FUNCTION rrs.interval_to_seconds(interval) AS IMPLICIT;
> CREATE CAST
> decibel=# select cast('1 month'::interval AS seconds);
> ERROR: cannot cast type interval to seconds
Given the current coercion rules, we should probably disallow attempts
to define casts that involve domains. Casts are on base types. The
down-cast from a domain to its base type is hardwired, and the up-cast
from base type to domain is too (with invocation of any constraints
that may apply). Adding random user-defined casts to this would
probably just create confusion and ambiguity. In particular, this
was already meaningless:
decibel=# create domain rrs.seconds as double precision;
CREATE DOMAIN
decibel=# create cast (double precision as rrs.seconds) WITHOUT FUNCTION AS IMPLICIT;
CREATE CAST
since the presence of the cast might be thought to justify coercing
floats to "seconds" without invoking domain constraints.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Hagop H. | 2005-03-04 21:07:52 | PostgreSQL installation problem on Windows XP Home |
| Previous Message | Richard Huxton | 2005-03-04 19:47:11 | Re: Casting from a domain |