Thread

Re: Re: BIT/BIT VARYING status

Adriaan Joubert <a.joubert@albourne.com> — 2000-11-05T18:52:25Z

Peter,

	I've looked at the current implementation of the bit types and still
have some doubts concerning the following issues:

1. Constants. The current behaviour just seems somewhat strange, and I
have no idea where to fix it.

test=# select B'1001';
 ?column? 
----------
 X9
(1 row)

test=# select B'1001'::bit;
ERROR:  Cannot cast this expression to type 'bit'
test=# select B'1001'::varbit;
ERROR:  Cannot cast this expression to type 'varbit'
test=# select 'B1001'::varbit;
 ?column? 
----------
 B1001
(1 row)

test=# select 'B1001'::bit;
 ?column? 
----------
 X9
(1 row)

test=# select X'1001'::varbit;
ERROR:  varbit_in: The bit string 4097 must start with B or X
test=# select 'X1001'::varbit;
     ?column?      
-------------------
 B0001000000000001
(1 row)

test=# select 'X1001'::bit;
 ?column? 
----------
 X1001
(1 row)

test=# select X'1001'::bit;
ERROR:  zpbit_in: The bit string 4097 must start with B or X

Also, I have two output routines, that have been renames to zpbit_out
and varbit_out. In fact, both will work just fine for bot bit and
varbit, but the first prints as hex and the second as a bit string.
Printing as hex is more compact, so good for long strings, but printing
as a bit string is much more intuitive. One solution would be to make
them both print to a bit string by default and define a function to
generate a hex string. Another would be to have this under control of a
variable. Most people who contacted me about bit strings seemed to want
to use them for flags, so I guess the default should be to print them as
a bit string.

More for my information, if a user does not know about varbit, how does
he cast to bit varying? 

2. This is not a problem, more a question. There is no default way to
compare bit to varbit, as in 

test=# select 'b10'::bit='b10'::varbit;
ERROR:  Unable to identify an operator '=' for types 'bit' and 'varbit'
        You will have to retype this query using an explicit cast

This may be a good thing, as the comparison does depend on the lenght of
the bit strings.

3. The ^ operator seems to attempt to coerce the arguments to float8?

select 'B110011'::bit ^ 'B011101'::bit;
ERROR:  Function 'float8(bit)' does not exist
        Unable to identify a function that satisfies the given argument
types
        You may need to add explicit typecasts

4. This is a policy question. When I use the bit shift operator, this
always shifts within the current string only. So if I do

select ('B010'::bit(6) >> 2)::varbit;
 ?column?  
-----------
 B000100

I get what I would expect. But if I have a bit varying(6) field (in a
table, this is just an example), I only get

select ('B010'::varbit >> 2)::varbit;
 ?column?  
-----------
 B000

which I find counter-intuitive. I have thus added 'zpshiftright' and
'varbitshiftright' functions. The second extends the bitstring to the
right, while the first is the old bitshiftright function. I find this
more intuitive at least. 

Question is what a shift left function should do? Should I shorten the
string in the case of a shift left, to keep it symmetrical to shift
right? This seems a pure policy decision, as there are arguments for
both behaviours, although I am a great fan of symmetry. Let me know and
I can implement a separate function.


I have made a start on a file for regression tests, which I append with
the diffs for the varbit files. Please let me know what else is needed
and where I can help.


Thanks!

Adriaan