Leonardo F wrote: >> In the documentation, the get_bit and set_bit methods are added >> to a list where we state "The following SQL-standard functions >> work on bit strings as well as character strings"; however they >> are not SQL-standard functions and are implemented on binary >> strings, not character strings. > > Ok, I didn't change that, but I guess I can fix it. The items already on that list, and substring function that you added, *do* fit the description; get_bit and set_bit don't fit that description, so they don't belong on that list. They must be described in some other way. >> There is a peculiar omission from the patch -- it adds support >> for the overlay function to bit strings but not binary strings. >> Since the standard drops the bit string as a standard type in the >> 2003 standard, in favor of boolean type and binary string types, >> it seems odd to omit binary string support (which is defined in >> the standard) but include bit string support (which isn't). What >> the patch adds seems useful, and I don't think the omission >> should be considered fatal, but it would be nice to see us also >> cover binary strings if we can. > > Mmh, don't know how complicated that would be, but I can give it a > try: I guess it could be a simple SQL replacement (as for char > strings and bit strings?) The standard explicitly defines it as being equivalent to the substring and concatenation technique, so that should work. >> Well, there was one thing which is beyond my ken in this regard: >> I'm not sure that the cases from bits8 to (unsigned char *) are >> needed or appropriate, although on my machine they don't seem to >> hurt. Perhaps someone with a better grasp of such issues can >> comment. > > That's some kind of copy&paste from varlena.c byteaGetBit: I don't > know if they can be avoided. Ah, but there it's casting the result of VARDATA_ANY. Here you already have the value in a bits8 variable. I looked it over some more and I'm pretty confident we can omit those casts in bitsetbit. > [pointer is zero-based] > >> Ok; I found them bizarre too, but I kept it consistent. >> [int32 used for bit values] > > Same as above: I tried to be consistent. >> [ERRCODE_ARRAY_SUBSCRIPT_ERROR used when query has no array] > > Again, same as above: consistency; but I can change it if you want I'm not suggesting the above require changes; I mentioned those primarily for the benefit of whoever eventually commits this, to try to save time chasing down the issues. >> [questions use of oldByte and newByte local variables] > > I agree, you version is cleaner. Cool. Should look even tidier without those casts. :-) -Kevin
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers