On Sat, 2011-01-08 at 13:05 -0800, Jeff Davis 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@j-davis.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?
Another thought:
If we use timestamps, then that's 8 bytes each, meaning 16 bytes. Then,
there is the VARHDRSZ (now we're at 20), the flag byte (21), and the
range type oid (25). With alignment (if it's aligned at all), that's
either 28 or 32 bytes, which is starting to seem ridiculous.
Making it always varlena is kind of nice, because then if the upper or
lower bound is special (NULL or infinity), then we can omit it and save
some space. But I'm starting to think that it's not worth it, and we
should detect whether the subtype is fixed, and if so, make the range
type fixed length. That will save on the varlena header.
Any suggestions on how to represent/align these ranges?
Regards,Jeff Davis
