> In hindsight, it would likely be more consistent with this if we'd
> considered bitstrings to be LSB first when coercing them to/from integer,
> but whoever stuck that behavior in didn't think about it. Too late to
> change that now I'm afraid, though perhaps we could provide non-cast
> conversi
>
> That's SQL:99 6.22 general rule 11) c).
> (SV and TD are the source value and the target datatype for a cast.)
>
> In hindsight, it would likely be more consistent with this if we'd
> considered bitstrings to be LSB first when coercing them to/from integer,
> but whoever stuck that behavior in
Evan Carroll writes:
> Currently the behavior of bit-string extensions is pretty insane.
You've provided no support for this assertion, much less any defense
of why your proposed semantics change is any less insane. Also, if
I understood you correctly, you want to change the semantics of
casting
Currently the behavior of bit-string extensions is pretty insane.
SELECT b'01'::bit(2)::bit(4),
b'01'::bit(2)::int::bit(4);
bit | bit
--+--
0100 | 0001
(1 row)
I'd like propose we standardize this a bit. Previously, in version 8
compatibility was broke. From the Version 8 release not
