Scott Bailey <artacus@comcast.net> writes:
> As I pointed out off-list, I think the granularity for timestamp range
> should be limited to hours and smaller. Anything larger is asking for
> trouble. And quite honestly if they wanted day granularity, they should
> use date range.
I'm still not real clear on what the expected use-case is for this.
You're evidently envisioning applications where the allowed form of
an interval is constrained, but in the cases I can think of, the
constraints are a lot more convoluted than what you're proposing.
For example, if you're trying to do classroom scheduling, it might be
useful to constrain the periods to start and end on hour boundaries
--- but the next thing you'll want is to have it know that the "next"
slot after 5pm Friday is 8am Monday. Except on holidays. And then
there's the fact that my alma mater starts most hour-long classes on
the half hour.
I think that wiring such constraints into the low-level datatype is
doomed to failure. What you'd be better off with is a function that
finds the "next" period given a current period and some suitable
representation of the off-limits intervals. The argument for having
granularity wired into the datatype seems to boil down to just space
savings. I don't find that compelling enough to justify code
contortions and user-visible restrictions on functionality.
regards, tom lane
