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

From Peter Eisentraut
Subject Re: Re: BIT/BIT VARYING status
Date
Msg-id Pine.LNX.4.21.0011181632420.1331-100000@peter.localdomain
Whole thread Raw
In response to Re: Re: BIT/BIT VARYING status  (Adriaan Joubert <a.joubert@albourne.com>)
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)

Fixed.  (Prints '1001'.)

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

Works now.

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

Not sure what we'll do with this.  X'1001' is currently an integer.  
According to SQL it may be a bit string or a binary object, but I don't
have a clue how they decide it.  Maybe we should look at other
implementations.

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

Both print binary now.

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

Sounds okay.

> 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

Works now.

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

> Question is what a shift left function should do?

I'd say that having shift left and shift right be symmetrical (although
they're obviously not strict inverses) is definitely important.  I could
live both with shortening the string on shift left or with keeping the
string length fixed in shift right (as above).  Your call.

(I haven't installed your patch for this yet.  Please submit one that
implements whatever you think it should do completely both ways.)

> I have made a start on a file for regression tests,

I've put a modified version at http://www.postgresql.org/~petere/bit.sql
(and bit.out) for you to work with.

The substring tests are commented out because they cause the backend to
crash.  bitsubstr() needs to be modified to handle -1 as its third
argument, meaning "the rest of the string".


-- 
Peter Eisentraut      peter_e@gmx.net       http://yi.org/peter-e/



pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: WAL fsync scheduling
Next
From: Tom Lane
Date:
Subject: Re: WAL fsync scheduling