Re: Re: BIT/BIT VARYING status

From: Adriaan Joubert <a(dot)joubert(at)albourne(dot)com>
To: Peter Eisentraut <peter_e(at)gmx(dot)net>
Cc: PostgreSQL Development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Re: BIT/BIT VARYING status
Date: 2000-11-05 18:52:25
Message-ID: 3A05AC69.5066EE5D@albourne.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

Attachment Content-Type Size
bit.sql text/plain 6.1 KB
varbit.c.patch text/plain 3.6 KB
varbit.h.patch text/plain 573 bytes

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Hannu Krosing 2000-11-05 20:14:24 Re: Transaction ID wraparound: problem and proposed solution
Previous Message Tom Lane 2000-11-05 18:07:12 Re: Transaction ID wraparound: problem and proposed solution