Thomas Lockhart wrote:
>
> attypmod has been modified recently to contain two fields (each of 16
> bits) in a backward-compatible way. It can hold the size *and*
> precision of the numeric data types, and presumably should be used in
> a similar manner for your bit type.
>
> The problem is that you need another field which contains a length in
> bit units. Assuming that the second field in attypmod can't be used
> for this purpose, then istm that you will want to add a field to the
> data type itself. The character types have:
>
> length - total size of data, in bytes (4 bytes)
> data - body
>
> and you might have
>
> length - total size of data, in bytes (4 bytes)
> blen - total size of data, in bits (4 bytes)
> data - body
OK, I just saw th email from Tom Lane as well. So I will use attypmod as
the length of the bit string in bits, and use an additional byte, as
suggested here, for the actual length.
Jose recommended looking at the Ocelot database and I got it down. Turns
out they have a real big problem with the output of bit strings, but at
least I could figure out how they do the ordering. Looks as if it is
lexicographically from the least significant bit, i.e.
B'1' > B'10' > B'1100'
the only surprising thing was that they then have B'1000' > B'01000',
and my reading of the SQL standard says that it should be the other way
round. So I will just do the comparison from the least significant bit.
Cheers,
Adriaan
