Re: Patch: AdjustIntervalForTypmod shouldn't discard high-order data

Sam Mason <sam(at)samason(dot)me(dot)uk> writes:
> On Sun, May 31, 2009 at 06:32:53PM -0400, Tom Lane wrote:
>> There is some case to be made that we should throw error here,
>> which we could do by putting error tests where the attached patch
>> has comments suggesting an error test.

> With things as they are I think it would be useful to throw an error
> here; if the user means 25 hours they should say 25 hours!

Well, maybe, but I'm not really convinced. By the same logic, if the
column is INTERVAL MONTH and the user puts in '1 year 1 month', then
we ought to throw an error for that too. But AdjustIntervalForTypmod
is incapable of doing that because months and years are folded into
a single field. There is a logical reason for the difference --- 1 year
is always exactly 12 months whereas 1 day is not always exactly 24 hours
--- but that difference isn't acknowledged by the SQL standard, which
last I checked still pretends daylight savings time doesn't exist.

The real bottom line here is that our underlying implementation and
semantics for INTERVAL are considerably different from what the SQL
standard has in mind. AFAICS they intend an interval to contain six
separate numeric fields with "what you see is what you get" behavior.
We could argue some other time about whether that's a better design
than what we're using, but it's surely not going to change for 8.4.
My ambitions for the moment are limited to making sure that we accept
all spec-compliant interval literals and interpret them in a fashion
reasonably compatible with what the spec says the value is. I don't
feel that we need to throw error for stuff we used to accept in order
to meet that goal.

> It would only be different when the interval is used with values of type
> timestamptz, or am I missing something? How much sense does it make to
> have a timezone aware interval where this distinction is true and leave
> the current interval as timezone naive.

Doesn't seem practical, certainly not for 8.4. In any case I'm
uncomfortable with the idea that a value would be accepted at entry
and then fail later on depending on how you used it.

regards, tom lane