Re: Interval->day proposal

Michael Glaesemann <grzm@myrealbox.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