Re: Re: BIT/BIT VARYING status

Thanks Peter. I will download tomorrow when the new snapshot is
available. So how do we find out whether hex needs to be supported? I
see what you mean with ('1001' as bit), but shouldn't that be (B'1001'
as bit)? Certainly if hex values are allowed the first version is
ambiguous. I would have to make the error message a bit more sensible
though.

Adriaan

> 
> > Peter, I think it is a problem if the B or X are dropped from the input,
> > as that is the only way to determine whether it is a binary or hex
> > string.
> 
> Well, you just assume it's a binary string, because it's unclear as of yet
> whether you're going to get to handle hex strings at all.  However, I
> changed the scanner to include a leading 'b', so now it works:
> 
> peter=# select B'1001';
>  ?column?
> ----------
>  X9
> (1 row)
> 
> peter=# select B'1001' | b'11';
>  ?column?
> ----------
>  XC
> (1 row)
> 
> The output definitely ought to be in binary though ("b1001").
> 
> You also might want to make the leading 'b' optional because this seems
> confusing:
> 
> peter=# select cast ('1001' as bit);
> ERROR:  zpbit_in: 1001 is not a valid bitstring
> 
> > Also, on output, shouldn't we poduce B'xxxx' and X'yyyyy' to conform
> > with the input strings?
> 
> If you did that, then your input function has to be prepared for values
> like "B'1001'".  (Think copy out/copy in.)  I think the above plan should
> work okay.
> 
> --
> Peter Eisentraut      peter_e@gmx.net       http://yi.org/peter-e/