Re: Range types
От | Tom Lane |
---|---|
Тема | Re: Range types |
Дата | |
Msg-id | 9936.1260997064@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Range types (Jeff Davis <pgsql@j-davis.com>) |
Ответы |
Re: Range types
Re: Range types |
Список | pgsql-hackers |
Jeff Davis <pgsql@j-davis.com> writes: > On Wed, 2009-12-16 at 13:59 -0500, Tom Lane wrote: >> 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. > The argument (at least from me) is that discrete ranges have better > semantics. The counterargument was that the granularity of a timestamp > is an implementation detail. So I countered by making it explicit. Making it explicit doesn't fix the fact that you can't rely on the arithmetic to be exact. > I still have not seen an answer to the problem of changing the > representation of a continuous range. If you have the continuous range > [5, 10], you're pretty much stuck with that representation, even if the > application is expecting things in the form [ ). That is not our problem. It's the application's problem if it can't handle the concept. You might as well be complaining that type numeric is broken because it can represent values that will fail to fit into float8 when some application tries to force them into that form. > And to further make the case for allowing user-defined discrete ranges, > what about ip4r? What about it? I don't have a problem with the concept that next() is well defined for some datatypes. I just have a problem with the concept that it's well-defined for timestamps. It's not, and I don't believe that forcing it to have some definition is useful in the real world (which, as a rule, isn't going to fit the simplifying assumptions you have to make to make it even sort-of work). regards, tom lane
В списке pgsql-hackers по дате отправления: