Re: Re: BIT/BIT VARYING status - Mailing list pgsql-hackers

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@gmx.net       http://yi.org/peter-e/