Thomas Lockhart writes:
> SQL9x defines bit string constants with a format like
>
> B'101010'
> and
> X'ABCD'
>
> for binary and hexadecimal representations. But at the moment we don't
> explicitly handle both of these cases as bit strings; the hex version is
> converted to decimal in the scanner (*really* early in the parsing
> stage) and then handled as an integer.
The sole reason that this is still unresolved is that the SQL standard is
ambiguous about whether a literal of the form X'something' is of type bit
(<hex string literal>) or of type blob (<binary string literal>). If I
had to choose one, I'd actually lean toward blob (or bytea in our case).
Two ideas: 1. make an "unknownhex" type and resolve it late, like the
"unknown" type. 2. allow an implicit cast from bytea to bit.
> It looks like our current bit string type support looks for a "B" or "X"
> embedded in the actual input string, rather than outside the quote as in
> the standard.
This was a stopgap measure before the B'' syntax was implemented. I guess
it's grown to be a feature now. :-/
> 1) the SQL standard says what hex values should be translated to in
> binary, which implies that all values may be *output* in binary format.
> Should we do this, or should we preserve the info on what units were
> used for input in the internal storage? Anyone interpret the standard
> differently from this??
I believe you are caught in the confusion I was referring to above: hex
values are possibly not even of type bit at all.
--
Peter Eisentraut peter_e@gmx.net
