nielspardon commented on code in PR #5073:
URL: https://github.com/apache/calcite/pull/5073#discussion_r3549435527
##########
core/src/main/java/org/apache/calcite/runtime/SqlFunctions.java:
##########
@@ -3914,6 +3914,148 @@ public static ULong leftShift(ULong x, int y) {
return ULong.valueOf(val);
}
+ /**
+ * Performs PostgresSQL-style bitwise shift on a 32-bit integer.
+ *
+ * @param x the integer value to shift
+ * @param y the shift amount (positive: right shift, negative: left shift)
+ * @return the shifted integer
+ */
+ public static int rightShift(int x, int y) {
+ int shift = ((y % 32) + 32) % 32; // normalize to 0~31
+ return y >= 0 ? x >> shift : x << shift; // arithmetic right shift
+ }
+
+
+ // ----------------- long -----------------
+ /**
+ * Performs PostgresSQL-style bitwise shift on a 64-bit long value.
+ *
+ * @param x the long value to shift
+ * @param y the shift amount
+ * @return the shifted long value
+ */
+ public static long rightShift(long x, int y) {
+ int shift = ((y % 64) + 64) % 64; // normalize to 0~63
+ return y >= 0 ? x >> shift : x << shift;
+ }
+
+ /**
+ * Performs PostgresSQL-style bitwise shift on an int value with a long
shift amount.
+ *
+ * @param x the int value to shift
+ * @param y the long shift amount
+ * @return the shifted value as long
+ */
+ public static long rightShift(int x, long y) {
Review Comment:
Done. All `leftShift`/`rightShift` overloads now take a `long` shift amount,
so an `int` amount widens automatically during codegen (`EnumUtils.call`
resolves by widening) and a single amount type covers every value type — which
let me drop the redundant `(int, long)` overloads and answers "why no long-`y`
for these?" too.
It also closes a real gap: there was no `(long, long)` overload, so an
*executed* `BIGINT >> BIGINT` would have failed to resolve at code generation —
only `checkType` (which doesn't execute) was covering it. I added executed
BIGINT-by-BIGINT cases for both the operator and function forms.
On the unsigned shift *amount*: I added a test, and it's currently rejected
at validation — the second operand's family is signed `INTEGER`, so `a >>
CAST(x AS INTEGER UNSIGNED)` is a `Cannot apply` error today (documented via
`checkFails`). I left that as-is, since allowing it would be a separate change
that also touches the released `LEFTSHIFT`; happy to file a follow-up if you'd
like unsigned amounts supported.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
