Re: Ranges for well-ordered types
От | Jim C. Nasby |
---|---|
Тема | Re: Ranges for well-ordered types |
Дата | |
Msg-id | 20060611152722.GD34196@pervasive.com обсуждение исходный текст |
Ответ на | Re: Ranges for well-ordered types (Michael Glaesemann <grzm@seespotcode.net>) |
Список | pgsql-hackers |
On Sun, Jun 11, 2006 at 03:22:55PM +0900, Michael Glaesemann wrote: > > On Jun 11, 2006, at 14:45 , Bruno Wolff III wrote: > > >On Sun, Jun 11, 2006 at 10:18:11 +0900, > > Michael Glaesemann <grzm@seespotcode.net> wrote: > >> > >>Time (and timestamp) is a bit of a issue conceptually. The "default" > >>successor function would depend on the precision of the timestamp. > > > >And in the ideal case it doesn't exist. That is why I think a > >closed, open > >interval is a better way to go. > > How would you go about converting a closed-open representation to a > closed-closed representation for display purposes? Or inserting data > that is provided in closed-closed representation? Perhaps it makes more sense to consider the four possibilities { ( ), ( ], [ ), [ ] } as different data types. I realize that mathematically, there's probably plenty of reasons to convert between closed and open on both ends (though I admit I can't think of any reason to do this), but my focus is on what I believe to be (by far and away) the most common PostgreSQL use case: defining timestamp ranges. And that's something that needs to be closed, open. (Sadly, I see people mess that up frequently.) If this case can be well satisfied by an interval type that depends on a sucessor function without a bunch of complexities (in code or operation), then that's great. I'm worried that that's not the case (the issue of various timestamp precisions is worrying enough by itself), and I'd much rather see a solid closed, open interval added than nothing at all. -- Jim C. Nasby, Sr. Engineering Consultant jnasby@pervasive.com Pervasive Software http://pervasive.com work: 512-231-6117 vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461
В списке pgsql-hackers по дате отправления: