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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
