Re: BUG #1578: ::bit(n) behaves "differently" if applied to bit

Thanks very much Bruce and Tom for your responses and explanations. The
current mode of operation is mathematically disturbing so I'm hoping that you
can figure out some sort of a fix! Perhaps this example is a little more
convincing than my last one at showing the bug/feature:

949 base 10 = 1110110101 base two.

select 949::bit(10) gives 1110110101 (as expected).
select 949::bit(10)::bit(3) gives 111 (the 3 most significant bits)
select 949::bit(3) gives 101 (the 3 least significant bits).

As a mathematician, I'd certainly at least want the last two selects to give
the same results!

Whether the least or most significant bits are given is negotiable, though in
most things I do with bitstrings it would be more convenient to get the least
significant bits (as I guess was the case before 8.0, and which is still what
8.0 does in casting from integer to bit(n).).

If my example above does not convince you, can you please point me to the
arguments which the previous complainers used to convince the postgresql
developers to change the bit() casting behaviour in 8.0? It would certainly
seem to me that the old way was better mathematically! Perhaps their desires
could have been handled with some new bit handling function rather than
through a change in how things are casted?

Thanks for your help,
Celia McInnis

On Wed, 11 May 2005 01:36:51 -0400, Tom Lane wrote
> Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> > ... Though this is slightly inconsistent in how it works with a
> > bit string, it does seem the most useful approach.
>
> Also, this is a behavior that we changed in 8.0 in response to previous
> complaints. Before changing it again, I'd want to see a pretty detailed
> analysis of either (1) why the previous complainers were idiots, or
> (2) why this change is still compatible with what they asked for ;-)
>
> Where relevant, comments on SQL spec compliance would help the argument
> too. I don't think the spec defines any bit<->integer conversions,
> but it definitely addresses the issue of converting from bit(m) to
> bit(n).
>
> regards, tom lane

--
Open WebMail Project (http://openwebmail.org)