Re: Bitmask trickiness

Поиск
Список
Период
Сортировка
От Stephen Cook
Тема Re: Bitmask trickiness
Дата
Msg-id 4C4967A1.2070906@gmail.com
обсуждение исходный текст
Ответ на Bitmask trickiness  (Howard Rogers <hjr@diznix.com>)
Ответы Re: Bitmask trickiness  (Howard Rogers <hjr@diznix.com>)
Список pgsql-general
On 7/23/2010 5:33 AM, Howard Rogers wrote:
> ...so select * from table where 21205 | 4097 = 21205 would correctly
> grab that record. So I'm assuming you mean the 'stored value' should
> be on both sides of the equals test. If so, that would indeed seem to
> be the ultimate answer to the question (though I wouldn't myself call
> it a 'plain old equals' :-) )
>
>> Hope I was clearer this time. Originally I just fired off a quickie email to
>> get you past your coder's block.
>
> I do indeed think the magic of "BIT OR" is the missing ingredient I
> was looking for, and I very much appreciate your help leading me to
> it. My apologies for being too dense to spot what you were talking
> about before.

I think I misunderstood you the whole time actually, or maybe was
injecting some of my other thoughts into your problem. I figured you
meant you wanted to find records where your probe value has exactly the
same bit pattern as your stored value (probe bits, and only probe bits,
set; hence the "plain old equals"). Rather (and I just confirmed this
looking at the OP) you want any records where the stored value has all
of the probe value's bits set, regardless of the other bits in the
stored value.

So yeah, check if ORing the stored and probe values equals the stored value.

Oh well, even if I misread, glad to help you stumble upon what you
wanted eventually.

-- Stephen

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

Предыдущее
От: "Machiel Richards"
Дата:
Сообщение: Data dumps to files - best methods?
Следующее
От: Tom Robst
Дата:
Сообщение: Centos 5.5 and Postgres 9.0.beta3 install errors