On Tue, 2009-12-15 at 13:15 -0500, Tom Lane wrote: > You probably need some flag bits anyway, so flailing frantically to > avoid that doesn't seem like a profitable use of time.
I think "need" and "flailing" are both a little too strong here. The biggest use case will almost certainly be ranges of timestamps, and most of those people will have no use for flag bits (or if they do, it might not be worth an 8-byte-per-value overhead). > One pretty obvious use for a flag bit is open-ended ranges, ie > range(something, infinity) > You could only do this without a flag bit if the underlying datatype > has an "infinity" value, which not all do. True, but frustrating for people whose primary use case is timestamps or floats, which already have 'infinity'. Also frustrating for people who don't mind using the min/max integer as a workaround. > I'm also wondering what null range boundaries would do. Maybe that's > the same as the infinity case, or maybe not. I would prefer to avoid allowing NULL range boundaries for the following reasons: * it reminds me of MySQL dates with zeros in them * we are not guided by any kind of standard * we'd have to invent semantics that are pretty far outside of those defined for mathematical intervals * we could easily create more confusion or allow subtle traps for users * we aren't guided by a clear use case (or I haven't seen it) that isn't equally solvable (or better) using some other method * would impose that extra 8-byte storage burden on people who may not need any flag bits 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