Re: Extending a bit string

Поиск
Список
Период
Сортировка
От Evan Carroll
Тема Re: Extending a bit string
Дата
Msg-id CAAiePB60y4hTr+L_8S_Y57WWU6o2PiP055hR7w6tpuvAY7Xq9Q@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Extending a bit string  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
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@evancarroll.com
System Lord of the Internets
web: http://www.evancarroll.com
ph: 281.901.0011

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Jonathan Rudenberg
Дата:
Сообщение: Re: [sqlsmith] Unpinning error in parallel worker
Следующее
От: Alvaro Herrera
Дата:
Сообщение: Re: Should we add GUCs to allow partition pruning to be disabled?