Re: Range Types, discrete and/or continuous

From: Jeff Davis <pgsql(at)j-davis(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Range Types, discrete and/or continuous
Date: 2010-10-25 18:27:29
Message-ID: 1288031249.8645.30.camel@jdavis-ux.asterdata.local
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, 2010-10-25 at 13:00 -0400, Robert Haas wrote:
> I'm still confused. It seems to me (and maybe I'm full of it) that
> the distinction between continuous ranges and discrete ranges is
> pretty minor. Suppose you have continuous ranges done, and working.
> The only thing you need to add for discrete ranges (I think) is a
> canonicalization function that converts a range with one or both ends
> open to a range with both ends closed. Then you just apply this
> canonicalization functions to every value supplied by the user before
> doing anything else with it. Poof, discrete ranges! What am I
> missing?

That's not too far from what I'm suggesting. On the wiki page, under
"approach 2" you'll see that one of the functions needed is a
"constructor" which would put it into a canonical form (if applicable)
and construct the representation.

I think the difference is that I assumed that the UDFs used for the type
definition would handle both canonicalization and representation. I
think what you're suggesting is that postgres could handle
representation, and just always call the UDF to put it in canonical form
first. That might make it easier to define new types, but might limit
any representation optimizations that certain range types may be able to
exploit. Either approach seems reasonable to me.

I know the wiki page isn't very formal about the approaches yet, but as
we start to coalesce around a basic idea I'll write it up in more
detail.

Regards,
Jeff Davis

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Divakar Singh 2010-10-25 18:31:22 Re: Postgres insert performance and storage requirement compared to Oracle
Previous Message Scott Marlowe 2010-10-25 18:26:27 Re: Postgres insert performance and storage requirement compared to Oracle