bytea bitwise logical operations implementation (xor / and / or / not)
Hackers,
Currently, `bytea` does not have any bitwise logical operations yet.
This issue came up in an old thread from 2006 [1]/messages/by-id/5171.1146927915@sss.pgh.pa.us, but nobody seemed to
have picked this issue so far.
Being in the need for this myself, I copied the bit vector's bitwise
logical operations and converted them to bytea. I'm using this as a
PostgreSQL extension right now, but would be very happy to see this
integrated into mainstream as default bytea operations in the future.
Find attached the implementation, plus a SQL file, for:
* bytea_xor
* bytea_and
* bytea_or
* bytea_not
* bytea_bitsset (returns number of set bits in a bytea; feel free to
drop this one if you don't see utility)
Tested on PG 9.6. I hope you find this useful.
Cheers,
Christian
Hello Christian,
Currently, `bytea` does not have any bitwise logical operations yet.
This issue came up in an old thread from 2006 [1], but nobody seemed to
have picked this issue so far.
I remember this one because I needed them for checksuming set of rows.
There is a whole set of missing (from my point of view) operators, casts
and aggregates.
See https://github.com/zx80/pg_comparator where I packaged the subset I
needed as an extension. In particular, there is a bitxor which can be used
for bytea if casting is allowed.
Tested on PG 9.6. I hope you find this useful.
I think that the probability of getting these useful things into pg is
alas small. In the mean time, you may package and register it as an
extension?
--
Fabien.
Hello,
working with binary is certainly lacked in Postgres.
I would be happy if these can be pulled in to Postgres, as there's not
always a possibility to install a C based extension, and bit tricks are
needed for efficient SQL-level implementations of custom datatypes.
Another bitwise thing, when I was implementing a custom interval type, I
lacked a way to set bits from i to j in bit vector. It's probably doable
with clever and-or-xor tricks, but that would imply a lot of allocations of
temporary bit vectors.
For reference, it was subset of OpenStreetMap opening_hours spec
implementation.
Implementation I came up with:
https://github.com/gojuno/lostgis/blob/master/sql/types/type_opening_hours.sql
Hi Fabien,
I think that the probability of getting these useful things into pg is
alas small. In the mean time, you may package and register it as an
extension?
I aimed to close the asymmetry between bit vector operations (they also
offer xor/and/etc.) and bytea operations. My code is more or less a 1:1
copy of the corresponding bit vector operations (in fact, just a tiny
bit easier, since bytea is byte-aligned, wheres bit vectors aren't).
I just wanted to dump the code here, given that Tom suggested (in 2006)
such an implementation might be a useful addition to bytea. But I won't
feel offended in any way if the code won't be merged.
Cheers,
Christian
On 13 January 2018 at 01:57, Christian Rossow <christian.rossow@gmail.com>
wrote:
Hi Fabien,
I think that the probability of getting these useful things into pg is
alas small. In the mean time, you may package and register it as an
extension?I aimed to close the asymmetry between bit vector operations (they also
offer xor/and/etc.) and bytea operations. My code is more or less a 1:1
copy of the corresponding bit vector operations (in fact, just a tiny
bit easier, since bytea is byte-aligned, wheres bit vectors aren't).I just wanted to dump the code here, given that Tom suggested (in 2006)
such an implementation might be a useful addition to bytea. But I won't
feel offended in any way if the code won't be merged.
Seems like a good idea to me.
Conversion between bit varying and bytea would be a big help.
So would casts from bit varying or bytea <-> integer and other types.
--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services