Add support for SQL bitwise operators on integer types

[aalexandrov]

Motivation

Adds missing bitwise operators on integers as suggested in #7192.

Description

Adds the following bitwise operators on smallint, int, and bigint types

• Bitwise AND (&)
• Bitwise XOR (#)
• Bitwise OR (|)
• Bitwise NOT (~)
• Shift left (<<)
• Shift right (>>)

Tips for reviewer

• I used sql: add right string function #5966 to figure out what changes are needed.
• I had to add a new precedence for the bitwise NOT in order to maintain compatibility with Postgres (see diff in parser.rs). Note that this is different from the CockroachDB semantics which are not aligned with Postgres.

Checklist

• This PR has adequate test coverage.
• This PR adds a release note for any user-facing behavior changes.

[CLAassistant]

All committers have signed the CLA.

[antiguru]

Could the unary funcs be expressed as a macro? Not sure tbh, but maybe worth checking!

[aalexandrov]

Probably, but this issue is more general, as most functions come in families indexed by the possible combination of types (e.g. see neg_int{XX}, abs_int{XX}, ...). I agree that we should think how we can minimize code for this functions, but I prefer to not tackle this as part of my starter issue. We could use a macro, think about how to utilize generics in a better way, or choose another zero cost abstraction.

I'm happy to open a follow-up issue if more people agree that this is a problem.

[philip-stoev]

@petrosagg ^^^

[antiguru]

I was thinking about something like this:

sqlfunc!(
    fn bit_not_int16(a: i16) -> i16 {
        !a
    }
);

Elsewhere, there seems to be a TryFrom missing:

impl TryFrom<Datum<'_>> for i16 {
    type Error = ();
    fn try_from(from: Datum<'_>) -> Result<Self, Self::Error> {
        match from {
            Datum::Int16(f) => Ok(f),
            _ => Err(()),
        }
    }
}

impl TryFrom<Datum<'_>> for Option<i16> {
    type Error = ();
    fn try_from(from: Datum<'_>) -> Result<Self, Self::Error> {
        match from {
            Datum::Null => Ok(None),
            Datum::Int16(f) => Ok(Some(f)),
            _ => Err(()),
        }
    }
}

But, totally up to you :D

[petrosagg]

Using the sqlfunc! macro for this unary function is totally doable and totally optional since this is your first issue. We're in the process of transitioning the traditional declarations (like the one you provided for bit_not_int16) to use sqlfunc!. The plan is to transition all functions (even binary and variadic), but for now only unarfy functions are supported by the macro.

So, if you want to merge as is, that's totally fine, I will include this function in a future PR that will migrate all the int16 functions whole sale.

If you want to dip your toes in the new way of defining unary functions you can use @antiguru's snippets above and a commit like this one for reference: 88a1443

[aalexandrov]

So, if you want to merge as is, that's totally fine, I will include this function in a future PR that will migrate all the int16 functions whole sale.

@petrosagg: I like the approach outlined in #7704! Unfortunately, missed that and started working on a this feature shortly before the PR was merged, so I prefer to merge the current PR without further. I am happy take off some of the refactoring work (including the ~ operator) in the next days.

Elsewhere, there seems to be a TryFrom missing:

@antiguru Is the above somehow affecting the correctness of the current implementation and actionable on my end?

[petrosagg]

No, TryFrom is only needed if you go down the sqlfunc! path. Don't worry, I'm slowly converting all the functions in batches, let's merge this as is :)

[petrosagg]

extra new line here

[aalexandrov]

I followed the formatting from the last few versions (line items are separated by a new line). I now realize this is not correct markdown, though (it will be interpreted as a sequence of singleton lists, so maybe we should omit the newlines as you are suggesting.

[antiguru]

LGTM once remaining comments are addressed! Thanks!