Christopher Kings-Lynne wrote:
>
> > Some SQL92 functionality is missing from the BIT and VARBIT types.
> >
> > It should be possible to enter hexadecimal values as:
> >
> > B'[<bit>...]'[{<separator>...'[<bit...]'}...]
> > X'[<hexdigit>...]'[{<separator>...'[<hexdigit...]'}...]
> >
> > (Cannan and Otten: SQL - The Standard Handbook, p.38)
> >
> > but the hexadeximal form is not accepted.
As Peter noted: the standard does not say whether X'..' should be a
blob, a bit or a varbit type. Converting it into an integer seems to me
to be the least reasonable solution, albeit the historical one, as
larger bitmasks will not fit. With TOAST the bit type can contain quite
large bit strings, so a case could be made for converting to bit
(especially as the blob implementation has reputedly got some problems).
>
> I have been using the BIT and VARBIT types in Postgres 7.0.3 (undocumented I
> believe), and I note that the _input_ format is as follows:
>
> update blah set flags='b101001'; -- Binary
> update blah set flags='xff45'; -- Hex
Yes, that was done due to limitations in the parser. These have been
fixed and this format should not be used any longer.
>
> But the _output_ format (for varbit) is always:
>
> B'1010110'
The SQL standard says nothing about the output of the BIT datatypes. The
C-routines to interpret both the B'..' and X'..' formats, as well as
output routines to generate both are implemented and included. The
problem is that a default had to be chosen, and the B'..' format seemed
more useful for people using small bit masks.
I don't know whether a function was defined to return an X'..' string of
a bit mask. I don't have one of the more recent Postgres snapshots down
at the moment. Peter E. may know, as he did all the integration.
An alternative may be to add a 'SET variable' to psql to govern the
output format, but there seem to be too many of those already.
Adriaan