Re: [HACKERS] bit type external representation
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. So the standard says both represent a fixed-length bit string data type. ISTM that we should not try to preserve any information on the units used for input, and that both should be output in the same way. OK, that's how I read it too. I'll work on making it behave with hex input and not worry about the output, which takes care of itself. I also notice that the following has trouble: thomas=# select bit '1010'; ERROR: bit string length does not match type bit(1) which is similar to the very recent problem with fixed-length character strings. I've got patches to fix this one too. - Thomas ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] bit type external representation
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
[HACKERS] bit type external representation
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. 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. I'd like to have more support for the SQL9x syntax, which requires a little more invasive modification of at least the scanner and parser. I have a couple of questions: 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?? 2) we would need to be able to determine the format style when a string is output to be able to reconstruct the SQL shorthand representation (if preserving binary or hex is to be done). So a column or value should have a corresponding is_hex() function call. Any other suggestions?? - Thomas ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] bit type external representation
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. 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. I should point out that this is probably for historical reasons; I'd implemented the hex to decimal conversion way before we had bit string support, and we didn't consolidate those features when bit strings came along. - Thomas ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] bit type external representation
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.
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.
Postgres supports both:
test=# create table test (a bit(3));
CREATE
test=# insert into test values (B'101');
INSERT 3431020 1
test=# insert into test values (b'101');
INSERT 3431021 1
test=# insert into test values ('B101');
INSERT 3431022 1
test=# insert into test values ('b101');
INSERT 3431023 1
test=# select * from test;
a
-
101
101
101
101
(4 rows)
In fact, some of our apps actually _rely_ on the old 'b101' syntax...
Although these could be changed with some effort...
Chris
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send unregister YourEmailAddressHere to [EMAIL PROTECTED])
