Re: [BUGS] BUG #14479: Casting non-constant values to INTERVAL DAY TO MINUTE doesn't truncate the seconds field
От | Tom Lane |
---|---|
Тема | Re: [BUGS] BUG #14479: Casting non-constant values to INTERVAL DAY TO MINUTE doesn't truncate the seconds field |
Дата | |
Msg-id | 31017.1482868843@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: [BUGS] BUG #14479: Casting non-constant values to INTERVAL DAY TO MINUTE doesn't truncate the seconds field (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-bugs |
I wrote: > I've not figured out exactly what's broken about interval_transform; > the bit-twiddling looks a bit fishy, but it may be that that's fine > and there's simply a thinko in the logic about which conversions > are no-ops. There seem to be multiple problems here. One is that this innocent-looking assumption: * Temporally-smaller fields occupy higher positions in the range * bitmap. is bunkum, as a quick look into dt.h confirms: #define MONTH 1 #define YEAR 2 #define DAY 3 #define HOUR 10 #define MINUTE 11 #define SECOND 12 Don't ask me why MONTH was listed before YEAR, but it is, and we don't really have the freedom to change these codes (especially not in the back branches). This function will just have to cope. However, that doesn't impact your specific bug; it means that casting INTERVAL MONTH to INTERVAL YEAR is mistakenly treated as a no-op. The other problem is that it's comparing the result of fls() to the constant SECOND, but that's not right because fls(1 << k) produces k+1 not k. So it's mistakenly reading the cast to INTERVAL DAY TO MINUTE as a cast to INTERVAL DAY TO SECOND, which indeed would be a no-op. regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
В списке pgsql-bugs по дате отправления: