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