From: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> |
---|---|
To: | Jeff Davis <pgsql(at)j-davis(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: casting between range types |
Date: | 2011-08-31 06:20:22 |
Message-ID: | 4E5DD2A6.60905@enterprisedb.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 31.08.2011 09:14, Jeff Davis wrote:
> At one point, the question of casting between range types came up. At
> first, this seemed like a fairly reasonable suggestion, but now I don't
> think I like the semantics.
>
> A normal cast changes between essentially equivalent values in different
> domains. For instance 3 as an int4 is equivalent to 3.0 as a numeric.
>
> However, if we take the simple approach with range types and cast the
> bounds, we end up with some weird situations.
>
> First, a range is really a set. So if we take '[1,10)'::int4range and
> cast that to numrange, we end up moving from a set of exactly 9 elements
> to a set of an infinite number of elements. Going the other way is
> probably worse.
>
> Sometimes casts are a bit "lossy" and I suppose we could write that off.
>
> But things get weirder when the total order is different (e.g. different
> text collations). Then you end up with a completely different set of
> values, which doesn't sound like a cast to me at all.
>
> So, I'm leaning toward just not providing any casts from one range type
> to another.
Can you only provide casts that make sense, like between int4 and
numeric range types, and leave out the ones that don't?
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Dean Rasheed | 2011-08-31 07:02:11 | Re: Inputting relative datetimes |
Previous Message | Jeff Davis | 2011-08-31 06:14:55 | casting between range types |