Re: Re: BIT/BIT VARYING status

Adriaan Joubert writes:

> 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)

That's because the zpbit output function chooses to represent values that
way. Whether or not it's good to do that is another question, but it's
legal as it stands. Then again, I do think that a binary output format
would be preferred.

> 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'

I notice now that casting of constants is handled separately, but it'll
get fixed.

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

That's because X'1001'-style constants get converted to integer currently.

> 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.

That's obviously not good.

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

CAST(value to BIT VARYING)

> 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

Ouch. I thought these types where binary equivalent, but evidently that
doesn't help here.

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

The ^ operator is exponentiation. We changed the xor operator to '#',
because we now also have bit-wise operators on integers, and making 'int ^
int' to do xor would have been very confusing.

> 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.

Really? I would expect 'b010'::bit(6) to be B'000010', thus shifting two
to the right gives 0.

> 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.

A few notes here: Do not use 'B10001' as bit input, use B'10001'. The
former is a text constant (sort of); it's only through the goodness of
heart that the system casts anything to just about anything else if
there's a way to get there, but I personally hope that we can stop it from
doing that sometime. The latter on the other hand is guaranteed to be a
bit string only (zpbit, to be precise).

That also means you do not have to put casts everwhere. You'd only need a
cast to varbit, but in that case write it as CAST(B'1001' AS BIT
VARYING(x)). Better yet, also be sure to have a few cases where bit and
bit varying are read from a table; that way you're really sure what type
you're dealing with.

--
Peter Eisentraut peter_e(at)gmx(dot)net http://yi.org/peter-e/