> > > Can I get comments on this? Is a bit type something we want installed
> > > by default, or in contrib? Seems to me it should be in the main tree.
> In this case just a single byte in which you can store states quite
> easily. It supports the C-style bit operations & (and) ,| (or, couldn't
> get it defined as a single bar though, because the parser didn't like
> it) ,^ (xor),! (not). For some applications it is just easier to check
> whether certain bits are set/not set.
As long as it is limited to a single byte, perhaps it should prove
itself in contrib. However, SQL92 has bit types, and it would be nice
to get full support for them (and beyond, as this already is doing :)
> If somebody tells me what needs doing, I could try to get it all into a
> more usable format. And I have no clue what SQL3 says about bit-types
> (varying bits or something or other?) At the moment it is just a single
> byte, and perhaps it needs extension to 2 byte, 4-byte types.
I don't have time right now to type up a short summary, but can do
that later if you like. But the data entry for an SQL92 bit type looks
like
B'10111' X'17'
The underlying data type is BIT(n), a fixed-length type where n is the
exact number of bits. BIT VARYING (n) allows a variable number of bits
(duh!) up to n bits. We can support these SQL92 constructs in the
parser, folding them into an internal type as we do for character
strings currently.
It could be implemented just like the character types, having a header
on the internal representation which holds the length. It can't re-use
the character type support functions as-is, since they currently
consider a zero byte in the string as end-of-string.
- Thomas
--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California