Dear Tom,
>>> I think that the inability to convert nearly binary compatible standard
>>> types one to the other is a postgresql issue. Even if it is not often
>>> useful, the point is completeness and soundness of the type provided by
>>> the core.
>
>> OK, can I get some feedback from others about this patch?
>
> I think Fabien is way overstating his case here.
Maybe.
> It's not immediately obvious that there should be a cast between bit(n)
> and bytea, and it's even less obvious that it should be done in a way
> that exposes the internal representation of bit(n) as this does.
Hmmm... I think people guessed it anyway;-)
Well, if there is a big/little endian issue, I agree that it is not a good
idea. As I cast at the byte level, it seems to me that it should be okay.
If so, I see no real harm in having an *explicit* cast allowed, which by
nature may be a little destructive, as long as it is reasonnable.
> There's no principled reason for one bit ordering over the other, for
> example, nor any very clean way to handle coercions where N isn't a
> multiple of 8.
It could be rejected instead.
> I think this request has more to do with a lack of adequate operators
> for one type or the other. If we're missing, say, bitwise logical
> operators for bytea, then let's add those rather than create a bogus
> equivalence between the types.
Indeed, what triggers my development for this cast was that I needed a xor
on md5 results, which can only be converted to bytea with convert. I could
develop a bunch of bitwise operators for bytea, but casting to varbit
where they are already available was the quickest path.
--
Fabien.
