Skip site navigation (1) Skip section navigation (2)

Re: casting between range types

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
Cc: Jeff Davis <pgsql(at)j-davis(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: casting between range types
Date: 2011-08-31 16:08:03
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On Wed, Aug 31, 2011 at 11:36 AM, Heikki Linnakangas
<heikki(dot)linnakangas(at)enterprisedb(dot)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
The Enterprise PostgreSQL Company

In response to

pgsql-hackers by date

Next:From: Bruce MomjianDate: 2011-08-31 16:16:03
Subject: Re: [GENERAL] pg_upgrade problem
Previous:From: Andrew DunstanDate: 2011-08-31 15:36:26
Subject: Re: rename index fields bug

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group