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

Re: Range types

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Jeff Davis <pgsql(at)j-davis(dot)com>
Cc: Scott Bailey <artacus(at)comcast(dot)net>, hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Range types
Date: 2009-12-14 18:32:08
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
Jeff Davis <pgsql(at)j-davis(dot)com> writes:
> On Mon, 2009-12-14 at 11:25 -0500, Tom Lane wrote:
>> This statement seems to me to demonstrate that you don't actually
>> understand the concept of open and closed ranges.

> Of course you can still define the obvious "contains" and "overlaps"
> operators for a continuous range. But there are specific differences in
> the API between a discrete range and a continuous range, which is what
> Scott was talking about.

Well, if the intention is to invent two different kinds of ranges, with
different operators, for continuous and discrete data types, then fine.
But the original post suggested no such thing, and provided (unworkable)
examples suggesting that the intent was to force every type to be
treated as discrete whether that makes any sense or not.

The main question I would have is how to tell whether the underlying
type is really discrete.  If we allow people to define things like
"range over float4 with 0.000001 step", then somebody will try to do it
--- and file bugs when it doesn't work sanely.  I don't think there is
anything in our API for user-defined types that really tells you whether
it's an exact or approximate type.

(Also, stuff like strings simply doesn't have any sane concept of a
unique next or previous value.  I think the number of types that are
really discrete in this sense is very small, like maybe just ints and

			regards, tom lane

In response to


pgsql-hackers by date

Next:From: Heikki LinnakangasDate: 2009-12-14 18:32:17
Subject: Re: Hot Standby, release candidate?
Previous:From: Alvaro HerreraDate: 2009-12-14 18:31:30
Subject: Re: Range types

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