[HACKERS] casting between range types
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. Thoughts? Regards Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] casting between range types
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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] casting between range types
On Wed, 2011-08-31 at 09:20 +0300, Heikki Linnakangas wrote: On 31.08.2011 09:14, Jeff Davis wrote: 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. ... Can you only provide casts that make sense, like between int4 and numeric range types, and leave out the ones that don't? There are certainly some casts that make sense, like int4range-int8range. Do you think int4range-numrange also makes sense? Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] casting between range types
On 31.08.2011 18:09, Jeff Davis wrote: On Wed, 2011-08-31 at 09:20 +0300, Heikki Linnakangas wrote: On 31.08.2011 09:14, Jeff Davis wrote: 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. ... Can you only provide casts that make sense, like between int4 and numeric range types, and leave out the ones that don't? There are certainly some casts that make sense, like int4range-int8range. Do you think int4range-numrange also makes sense? Not sure. It depends on whether you think of '[1,8]'::int4range as a finite set of the integers between 1 and 8, or as a continuous range from 1 to 8. I don't see harm in providing explicit casts like that, but I would be very conservative with implicit and assignment casts. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] casting between range types
On Wed, Aug 31, 2011 at 11:36 AM, Heikki Linnakangas heikki.linnakan...@enterprisedb.com wrote: On 31.08.2011 18:09, Jeff Davis wrote: On Wed, 2011-08-31 at 09:20 +0300, Heikki Linnakangas wrote: On 31.08.2011 09:14, Jeff Davis wrote: 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. ... Can you only provide casts that make sense, like between int4 and numeric range types, and leave out the ones that don't? There are certainly some casts that make sense, like int4range-int8range. Do you think int4range-numrange also makes sense? Not sure. It depends on whether you think of '[1,8]'::int4range as a finite set of the integers between 1 and 8, or as a continuous range from 1 to 8. I don't see harm in providing explicit casts like that, but I would be very conservative with implicit and assignment casts. +1 for that approach. It's really annoying when you can't explicitly cast between data types, and it might be that you just allow coercion via I/O functions since it's unlikely to be a performance-critical operation. But I can't see why you would want any implicit or assignment casts at all. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
