Robert Haas <robertmhaas@gmail.com> writes:
> If we were doing this over again, I would argue that, with this
> on-disk representation, 0.7 months ought to be rejected as invalid
> input, because it's generally not a good idea to have a data type that
> silently converts a value into a different value that is not
> equivalent for all purposes. It is confusing and causes people to
> expect behavior different from what they will actually get. Now, it
> seems far too late to consider such a change at this point ... and it
> is also no good considering a change to the on-disk representation of
> the existing data type at this point ... but it is also no good
> pretending like we have a floating-point representation of months and
> days when we actually do not.
You know, I was thinking exactly that thing earlier. Changing the
on-disk representation is certainly a nonstarter, but the problem
here stems from expecting interval_in to do something sane with inputs
that do not correspond to any representable value. I do not think we
have any other datatypes where we expect the input function to make
choices like that.
Is it really too late to say "that was a damfool idea" and drop fractional
years/months/etc from interval_in's lexicon? By definition, this will not
create any dump/reload problems, because interval_out will never emit any
such thing. It will break applications that are expecting such syntax to
do something sane. But that expectation is fundamentally not meetable,
so maybe we should just make a clean break. (Without back-patching it,
of course.)
I'm not entirely sure about whether to reject fractional days, though.
Converting those on the assumption of 1 day == 24 hours is not quite
theoretically right. But it's unsurprising, which is not something
we can say about fractions of the larger units. So maybe it's OK to
continue accepting that.
regards, tom lane
