Re: Extending a bit string

> 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,

SELECT get_bit(1::bit(1), 0), get_bit(1::bit(2), 1);

But, this does

SELECT get_bit(B'1'::bit(1), 0), get_bit(B'1'::bit(2), 1);

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).

--
Evan Carroll - me(at)evancarroll(dot)com
System Lord of the Internets
web: http://www.evancarroll.com
ph: 281.901.0011