Re: Range Types: empty ranges

From: Jeff Davis <pgsql(at)j-davis(dot)com>
To: Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Josh Berkus <josh(at)agliodbs(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Range Types: empty ranges
Date: 2011-02-11 19:44:13
Message-ID: 1297453453.32395.24.camel@jdavis-ux.asterdata.local
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, 2011-02-11 at 13:08 -0600, Kevin Grittner wrote:
> It makes more sense in the context of a range of some type with a
> clearly defined granularity. Our accounting system, for example,
> can assign a new range of receipt IDs for each calendar year. If
> you want a variable to represent the receipts for traffic receipts
> for 2012, you might, in preparation for the upcoming year, define
> something to declare the range as '[12TR000001,12TR000001)'. When
> the first receipt is assigned as 12TR000001, that is updated to
> '[12TR000001,12TR000002)'. Just as an off-the-cuff example.
>
> Basically, with a type having well-defined granularity, a [) range
> could usefully represent, "start to last used", and start out empty.

I think this is trying to make a range into something that's not. A
range is a set of values with the additional constraint that there are
no "gaps".

Trying to incorporate a "start value" is adding extra information in
there, and it's not really a part of the same algebra. It sounds more
like a contiguous sequence with a "start value" and a "current value" to
me.

Sequences have other useful operations, like "next", and things like
"overlaps" don't really seem to make sense (at least not in a practical
way that I can tell).

Regards,
Jeff Davis

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2011-02-11 19:49:27 Re: ALTER TYPE 2: skip already-provable no-work rewrites
Previous Message Aidan Van Dyk 2011-02-11 19:35:53 Re: ALTER EXTENSION UPGRADE, v3