Philip Warner <pjw@rhyme.com.au> writes:
> At 12:14 AM 23/04/2003 -0400, Tom Lane wrote:
>> Is there a way out of this? I'm not sure.
> The problem will be avoiding breaking existing apps that have adapted to
> current functionality. I have no preference to endianness, but taking the
> current LSB-on-left approach, I would like to see:
> Cast(8 as bit(10)) => '0001000000'
> Cast(8 as bit(4)) => '0001'
That part we could do, I think, if you are willing to abandon the
assumption that the result of casting int to bit(n) and then to bit(m)
should agree with the result of casting int directly to bit(m). While
it seems a little weird, I doubt that many existing apps would actually
be affected. Casting to bit(32) (or bit(64) for int8) is really the
only case with useful behavior at the moment, so it's the only one
anyone will be using.
> B'1' # Cast(1 as bit(32)) => '00000000000000000000000000000000'
Eh? What is the # operator supposed to be doing here?
A more general point: while automatic padding of the narrower input
is clearly sensible for varbit, I'm not convinced that it's per-spec
for bit. You're effectively treating bit the same as varbit if you are
willing to change the length at the drop of a hat. Perhaps these
operators should only exist for varbit, or should demand inputs already
the same length for bit.
regards, tom lane