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.
---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster
