Re: Interval->day proposal

Michael Glaesemann <grzm(at)myrealbox(dot)com> writes:
> When the string is read by DecodeInterval, the "days" component is
> assigned to tm_mday. It seems relatively straightforward to use this
> input to provide the interval->day value. However, I'm wondering what
> range of days this the interval->day component can be expected to
> handle. tm_mday is an int value, which is only guaranteed to be 2
> bytes (though it may be larger), if I understand correctly.

Actually, practically all of the Postgres code assumes int is at least
32 bits. Feel free to change pg_tm's field to be declared int32 instead
of just int if that bothers you, but it is really quite academic.

> If interval->day can be stored in an int16, then the interval struct
> would be widened from 12 to 14 bytes. Are there concerns about
> widening the interval datatype?

I'd make the on-disk field an int32, taking the struct to 16 bytes.
Given that it already requires double alignment for the embedded
double-or-int8 field, it's likely that it effectively takes 16 bytes
anyway after you count padding effects. So I don't see any percentage
in trying to shave a couple bytes.

regards, tom lane