Alex Fekken (5/18/2013)[hr.When I said I would exclude the endpoints I was thinking of the continuous case, because it is the more general one (e.g. pick a number between 0 and 1).
In the continuous case you think it intuitive to assume the interval is open. I tend to think the opposite, because I think that "between a and b" refers to a 1-ball (or a 2-ball, when a and b are positions on a plane, and so on); a ball in a Euclidean space is compact (under the induced topology) and there's no reason for the definition of a ball in 1-dimensional Euclidean space to be different from the definition in higher dimensions, and of those four intervals only the one including both endpoints is compact. But usually in the continuous case I write the interval as for example (0,1), (0,1], [0,1) or [0,1] depending on which endpoint(s) I intend to include, and it would be nice if SQL could have a similar simple notation instead of "between". For ranges (discrete case), I use 1..9 instead of [1,9] and 2..8 instead of (1,9) so I feel strongly that the notation suggests that named bounds are included in the range case. So my mathematical background tells me to include endpoints.
I think the best way of dealing with ranges (which is what I think BETWEEN is trying to do) would be in the way SQL partition functions are defined because there are often multiple contiguous ranges to deal with. The moment you try the single out a single one of them you've got an issue with (or at least decisions to make about) the endpoints. Hugo avoided this by using integers, but coming from a mathematical background I prefer approaches and solutions that also work in, and are (or can be seen as) intuitive from, a more general perspective.
Yes, a nice way of indicating what to do about endpoints without reverting to direct use of the conjunction of two predicates would be preferable to "between", at least for those of us who are used to using notations that don't directly represent words (and I guess others could get used to it over time).