Evan Carroll <me@evancarroll.com> 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 a bitstring to a bitstring of a different length, which is
an operation that's defined by the SQL standard. You will get zero
traction on that unless you convince people that we've misread the
standard. Which is possible, but the text seems clear to me that
casting bit(2) to bit(4) requires addition of zeroes on the right:
11) If TD is fixed-length bit string, then let LTD be the length in
bits of TD. Let BLSV be the result of BIT_LENGTH(SV).
...
c) If BLSV is smaller than LTD, then TV is SV expressed as a
bit string extended on the right with LTD-BLSV bits whose
values are all 0 (zero) and a completion condition is raised:
warning - implicit zero-bit padding.
That's SQL:99 6.22 <cast specification> 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 didn't think about it. Too late to
change that now I'm afraid, though perhaps we could provide non-cast
conversion functions that act that way.
regards, tom lane