On Tue, 2011-01-04 at 12:21 -0500, Robert Haas wrote:
> > It doesn't allow for all of the suggested features. In particular, it
> > would not allow "granules" to be specified for discrete ranges. But on
> > balance, it seems like this is the most conceptually simple and I think
> > it satisfies the primary use cases.
>
> Maybe I'm missing something, but it seems like this approach could
> support granules. You just have to define the canonicalize function
> in terms of the granule.
I meant that it doesn't support them as an explicit, user-visible
concept.
The main drawback here is that only a select group of people will be
defining discrete range types at all, because it would require them to
define a function first. Perhaps that's for the best, because, (as Tom
pointed out) we don't want someone using floats and then specifying a
granule of '0.01'.
While we're talking about it, one question I had is: should the
canonicalize function be: /* works on the deserialized information right before serialization */ canonical(&flags,
&lower_bound,&upper_bound)
or /* works on the serialized form right after serialization */ range = canonical(range)
I would lean toward the latter because it's simpler on the user (and
allows non-C functions). But perhaps an efficiency argument could be
made for the former because it could avoid one round of
deserialize/reserialize when the representation is not already in
canonical form.
Regards,Jeff Davis
