In hindsight, it would likely be more consistent with this if we'd considered bitstrings to be LSB first when coercing them to/from integer, but whoever stuck that behavior in didn't think about it. Too late to change that now I'm afraid, though perhaps we could provide non-cast conversion functions that act that way.
I've been thinking about that, and that actually makes sense and I'd prefer to revert to the pre-8.0 behavior. I just wanted to speak up to retract that response too. In reality, I am used to the interger display as it currently is. The current behavior of the coercion to/from int enforces the bias that I have. It led me to believe that PostgreSQL would act like that consistently because that's what I am used to.
SELECT 5::int::bit(8);
bit
----------
00000101
As compared to 10100000. But fundamentally SQL and the current helper functions don't operate like that, so it's bizarre. Moreover, the difference between the two makes it very error prone. For example, this doesn't make sense,
I'm sure it would have been substantially less confusing if integers displayed their LSB on the left after casting. I think I would have figured out what was going on *much* faster. You were right on everything in your initial response (as I've come to expect).
