Re: Bitmask trickiness - Mailing list pgsql-general

From Stephen Cook
Subject Re: Bitmask trickiness
Date
Msg-id 4C4967A1.2070906@gmail.com
Whole thread Raw
In response to Bitmask trickiness  (Howard Rogers <hjr@diznix.com>)
Responses Re: Bitmask trickiness  (Howard Rogers <hjr@diznix.com>)
List 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 by date:

Previous
From: "Machiel Richards"
Date:
Subject: Data dumps to files - best methods?
Next
From: Tom Robst
Date:
Subject: Centos 5.5 and Postgres 9.0.beta3 install errors