Jeff Davis <pg...@j-davis.com> writes: > 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).
When the alternatives are a crippled implementation that might not do what I want at all, or a full-featured implementation that takes another 8 bytes per value, I'll take the second. The 8 bytes don't matter if it doesn't solve my problem. > I would prefer to avoid allowing NULL range boundaries for the following > reasons: > * it reminds me of MySQL dates with zeros in them If we use that notation to represent an open-ended interval, it seems perfectly reasonable to me. And it doesn't require any assumptions about whether the underlying type has an infinity. I think it's a seriously bad idea to tell people that they should depend on min or max values of a datatype to substitute for the lack of open-ended intervals. That sort of technique creates unnecessary implementation dependencies, and magic numbers (especially ones with a dozen or two digits in them) are bad things for readability in any case. To take just one example that's pretty near at hand: if type date had had an exact published max value that applications were hard-wiring into their code, we'd not have been able to change it to add 'infinity' as a special value. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers