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.


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.


---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

Reply via email to