From: | Jeff Davis <pgsql(at)j-davis(dot)com> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: WIP: Range Types |
Date: | 2011-01-09 02:12:00 |
Message-ID: | 1294539120.18031.3592.camel@jdavis |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sat, 2011-01-08 at 20:32 -0500, Robert Haas wrote:
> On Sat, Jan 8, 2011 at 4:05 PM, Jeff Davis <pgsql(at)j-davis(dot)com> wrote:
> > On Sat, 2011-01-08 at 15:47 -0500, Robert Haas wrote:
> >> On Sat, Jan 8, 2011 at 3:12 PM, Jeff Davis <pgsql(at)j-davis(dot)com> wrote:
> >> > Any ideas? Maybe, with alignment and a "flags" byte (to hold
> >> > inclusivity, infinite boundaries, etc.), the extra 4 bytes doesn't cost
> >> > much, anyway?
> >>
> >> I'd be really reluctant to bloat the range representation by 4 bytes
> >> to support an anyrange type. Better to defer this until the great day
> >> when we get a better typmod system, at least IMHO.
> >
> > Can you elaborate? How can we have generic functions without ANYRANGE?
> >
> > And without generic functions, how do we make it easy for users to
> > specify a new range type?
>
> Oh, hmm. What generic functions did you have in mind?
Well, input/output, comparisons, overlaps, intersection, minus, and all
the necessary GiST support functions.
Without generic functions, the only choices we have are:
* force the user to write and specify them all -- which doesn't leave
much left of my feature (I think the interface would be all that's
left).
* somehow generate the functions at type creation time
Any other ideas?
Regards,
Jeff Davis
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2011-01-09 02:58:43 | Re: WIP: Range Types |
Previous Message | Robert Haas | 2011-01-09 01:39:47 | Re: obj_unique_identifier(oid) |