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
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 |