postgresql bit string or not?

Question

I'm fiddling with bit string data type lately. And have quite curious about:

1. ... plus 5 or 8 bytes overhead depending on the length of the string @ the bottom of this doc page

2. how is it handled in other languages (PHP, Java, C#, C++, etc.) through drivers (Npgsql, ODBC, etc.)

For #1, it seems that using integer(smallint/bigint) will be much storage efficient, or maybe even gain in performance since integers are supported everywhere. Performing bit operations with integers rarely have any issue in programming languages. Then what is the point of introducing the data type? Only for cases that need large amount of bit masks? Bit field indexing maybe? I'm more curious about how bit field indexing is done in Pg.

For #2, I'm confused, more than just curiosity. Say, a simple case, what if I store week day bit masks in a bit(7) field, one bit for a day, with lowest as Monday. Then I query for the value in PHP and C++. What will I get? By document, it says I'll have a bit string. But bit string is not something I can use directly - as with integers. Then in this case, should I give up on bit field?

Can anyone elaborate a bit why/when should bit or bit varying be used?

[EDIT]---------------- I found a related post here

However, I don't have my head cleared yet. As said in the above post (& its comments), I clearly understand what is bit(n) and bit varying are for. But I'm wondering what are their status in programming languages. Say, as far as I can find, these two data types are represented as strings in PHP. Which is the least I would have expected.

Can anyone give a scenario that such column is best used?

Answer 1

Have a look at Igorw's blog. This article relates how clumsy binary string mechanisms are in PHP. I am also looking for a good way to represent bitvar postgres data type in PHP for Pomm but I do not have an absolute answer.