On Wed, 2009-12-16 at 15:57 -0500, Tom Lane wrote:
> Making it explicit doesn't fix the fact that you can't rely on the
> arithmetic to be exact.
Can't rely on what arithmetic to be exact? Int64 timestamps should
clearly work for granules of 1 second.
If the administrator can choose a timestamp format that can't accurately
represent whole seconds, that's not an argument that modeling based on
whole seconds is worthless. We can restrict float timestamps for ranges
as a special case, if we're that worried about people misusing them.
> > 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.
...except that we support float8. So if applications like to work float8
float8, we let them.
You're arguing that we should not support discrete time ranges (or even
allow such a type to be defined by a superuser) even though applications
and users may happen to model time that way.
Who are we to argue that all of those people are so wrong that we won't
even support their type? Especially when they may have just finished a
couple books on the subject[1][2] which told them to model it that way?
> > 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.
Ok, so we'll allow users to specify user-defined types for discrete
ranges? How should that be specified, and how will that differ from
earlier proposals?
Earlier you proposed that we hard-wire the set of types that are allowed
to be used for discrete ranges:
http://archives.postgresql.org/pgsql-hackers/2009-12/msg01278.php
Regards,Jeff Davis
[1] "Temporal Data and the Relational Model" by C.J. Date, et al.
[2] "Developing Time-Oriented Database Applications in SQL" by Richard
Snodgrass.
