Thomas Kellerer <spam_eater@gmx.net> writes:
> The SQL standard already specifies the format for "binary strings":
> <binary string literal> ::=
> X <quote> [ <space>... ] [ { <hexit> [ <space>... ] <hexit> [ <space>... ] }... ] <quote>
> [ { <separator> <quote> [ <space>... ] [ { <hexit> [ <space>... ]
> <hexit> [ <space>... ] }... ] <quote> }... ]
Yeah, and we do honor that:
regression=# select x'1234abcdf';
?column?
--------------------------------------
000100100011010010101011110011011111
(1 row)
... although I notice we don't allow spaces in the input, which seems
like something to fix. (On further investigation, it looks like the
optional spaces are new since SQL99, which probably explains why we
have not got 'em.)
> The data type for such a literal is somewhat "undefined":
> It is implementation-defined whether the declared type of a <binary string literal>
> is a fixed-length binary string type, a variable-length binary string type,
> or a binary large object string type
Hm, we think it's bit(N):
regression=# select pg_typeof(x'1234abcdf');
pg_typeof
-----------
bit
(1 row)
which is what the SQL standard *used* to say, before they unceremoniously
threw the bit types under the bus and replaced them with "binary strings".
I wonder how painful it would be to update that stuff to be compatible
with more recent versions of the standard. Or whether anyone really
cares --- people doing this in PG seem to be happy enough with bytea.
regards, tom lane
