On Tue, 2009-12-15 at 18:03 -0600, decibel wrote: > I think it would help the discussion if you could provide some real > examples. I suspect you're thinking of things like scheduling apps, > where it's important to be able to do things like "what's the next > available time slot?". There are probably ways to make that kind of > thing easier without resorting to discrete time.
I did provide some examples: http://archives.postgresql.org/pgsql-hackers/2009-12/msg01385.php I think the bottom line is that we can't expect all applications to understand all 4 inclusivity permutations. Think about how many applications you've seen with "start" and "end" entry boxes, and you have to pick up from the surrounding words what inclusivity it's expecting. If you're running two such applications at once and they share data (perhaps an entry app and a reporting app), or you're migrating from one to another, you have a problem if you can't convert the intervals to the expected format. I don't see it as "resorting to discrete time". I view discrete intervals as simpler in many ways: there exists a canonical inclusivity representation, and you can take that canonical representation and display it however you want. We should at least allow the user to specify that their range is discrete (even if only by a superuser). And the user should also be able to specify that they don't want null boundaries or extra infinity boundaries, so that they get back down to the 16-byte representation. > I find myself wondering if they were influenced by the technology > available at the time... No, it's entirely at the logical level. It's also not a very old book (2002). For another author that apparently likes to deal with discrete time, how about "Developing Time-Oriented Database Applications in SQL" by Snodgrass. It's free to download online, I believe. 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