Thread: 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], 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
[1]: https://www.postgresql.org/message-id/5171.1146927915%40sss.pgh.pa.us
Attachment
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.
Re: bytea bitwise logical operations implementation (xor / and / or / not)
From
Darafei "Komяpa" Praliaskouski
Date:
Hello,
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.
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:
Implementation I came up with:
Re: bytea bitwise logical operations implementation (xor / and / or /not)
From
Christian Rossow
Date:
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.