Evan Carroll <m...@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