On Thu, Jul 22, 2010 at 1:02 PM, Scott Marlowe <scott.marlowe@xxxxxxxxx> wrote: >> >> Why on Earth would I want to store this sort of stuff in a bit string?! > > Because you are manipulating bits and not integers? I guess there are > 10 kinds of people, those who like think in binary and those who > don't. > >> I don't know about you, but I find looking at 21205 a darn'd site >> easier than staring blankly at 101001011010101!! > > If the fifth bit means one thing, and the 7th bit means something > else, quick which of the following have the fifth bit set and the 7th > bit off: > > 01001101 (base2) > or > 77 (base 10) > > >> And, fundamentally, >> they mean precisely the same thing. > > Of course. But that wasn't my point, and by my example above, one is > much easier to figure out than the other if you're interested in bit > twiddling. > >> And the '&' function works as >> nicely with boring old decimals as it does with long-winded binaries, >> so I really don't see the point of making it more complicated than it >> needs to be -but I'm open to be enlightened on the matter! > > I fail to see how storing a binary as a binary and showing it as a > binary makes things more complicated. But I'm open to someone showing > me how that's true. At least hex or octal have direct and simple > conversions where each hex or octal digit represents 4 or 3 bits > respectively. Decimal does not. > >> Thanks for the second link though. I hadn't realised that PostgreSQL >> was so richly-endowed with bitwise functions. Specifically, it's got >> the bitwise XOR I was thinking it would be nice to have in these sorts >> of situations: >> >> ims=# select * from coloursample where colour # 10 = 0; >> recid | colour | descript >> -------+--------+------------------- >> 1 | 10 | Yellow and Orange >> (1 row) >> >> Not quite sure how to apply that to my more realistic example just >> yet, but I think this will be very helpful, so thank you! > > Note you can cast integer to bitstring, but there may be some odd > behaviour for sign bits and such. Which is again why I'd use the > right type for the job, bit string. But it's your project. > Quoting... > Because you are manipulating bits and not integers? I guess there are > 10 kinds of people, those who like think in binary and those who > don't. Er, no. 21205 is not an integer. It's an encoded bit of magic. > quick which of the following have the fifth bit set and the 7th >bit off: >01001101 (base2) >or >77 (base 10) I'll give you that one (except that the fifth bit isn't set and the 7th bit is on!!). Now repeat for 10 million records and see how you get on. Really, I don't have to visually inspect a record to work this stuff out! So what is easier on your eye for one record is completely irrelevant as far as my code is concerned! >one is >much easier to figure out than the other if you're interested in bit >twiddling. As I say, take an incredibly simple example and everything looks, er, simple. Point of fact, I happen to know that the '1' bit is set in 21205 simply by looking at the last digit and spotting that it's not even. Fat lot of good that does me when fetching 350,000 records that happen to match 'insurance claim'. >I fail to see how storing a binary as a binary and showing it as a >binary makes things more complicated Because it's NOT binary. It's an encoding. Whether that encoding is displayed in binary, fluent hebrew or klingon or imaginary numbers is really irrelevant to me. It happens that I can look at a decimal number and work out most things (if the number is 29438, it's a fair chance the 16384 bit is set, for example; if it's 4098, I know it's 4096 + 2. And so on.). If you're happier working with fancifully long strings of 1s and 0s, good on you: but it doesn't alter the fact that I'm working with encoded meanings, not binary digits and I prefer a nice, compact display of that encoding which doesn't involve hieroglyphics. >But it's your project. Indeed. Doesn't mean I can do it all on my own, of course. But if it's simply a question of personal preference, I'll take mine over yours, for projects I work on, if that's OK. No hard feelings! :-) Regards HJR -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
