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 [EMAIL PROTECTED] ---------------------------(end of broadcast)--------------------------- TIP 6: Have you searched our list archives? http://archives.postgresql.org
