From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
Cc: | Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>, PostgreSQL Patches <pgsql-patches(at)postgresql(dot)org> |
Subject: | Re: cast bytea to/from bit strings |
Date: | 2006-05-06 15:05:15 |
Message-ID: | 5171.1146927915@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-patches |
Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> Fabien COELHO wrote:
>> 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. 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.
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.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2006-05-06 16:25:41 | Re: [COMMITTERS] pgsql: Add SSL CRL support to libpq. |
Previous Message | Tom Lane | 2006-05-06 14:57:13 | Re: pgsql: Add SSL CRL support to libpq. |