> You might want to search the archives (or the wiki history, or the CVS
> history if it's been there since before we moved the TODO list to the
> wiki) for discussion of why that item was added to the TODO in the
> first place.
I read the thread:
http://archives.postgresql.org/pgsql-hackers/2004-02/msg00478.php
1) it is true that "getbit sounds a lot like what substring() does", but the same could be said for binary string
substring/get_byte;so IMHO get/set_bit should be present for bit string
2) it is not very clear to me how "setbit could actually be handled by replace()" (maybe "overlay" style?)
3) since I'm looking at byte string get/set_bit to understand how that works, I'm having a hard time understanding why
thebit indexes in get/set_bit are low-first based:
select get_bit(E'\\376\\376'::bytea, s) as b,s from generate_series(0,15,1) as s
b s
0 0
1 1
1 2
1 3
1 4
1 5
1 6
1 7
0 8
1 9
1 10
1 11
1 12
1 13
1 14
1 15
I understand this is the internal representation, but still: if someone asked me what the 8th bit in 1111111011111110
is,I would have said 1, not 0 (assuming the first bit has index '0'). Actually, David Helgason's patch
(http://archives.postgresql.org/pgsql-hackers/2004-01/msg00498.php)goes in this direction: note the
bitNo = 7 - (n % 8);
part. Using that algorithm would mean get/set_bit in bit string would behave differently from what they do in binary
string(IMHO it's the binary string implementation that is "wrong").
Leonardo
