exec: integer overflow isn't handled in plus or mult projection ops

[jordanlewis]

Currently, the addition projection ops don't handle integer overflow, but their equivalents in the Datum.Eval model do.

We should add overflow detection, assuming that it actually is important. It's unclear to me whether overflow detection is required by the SQL standard, or indeed important to users. Postgres does have it, but it was introduced relatively recently, in 2004: https://www.postgresql.org/message-id/[email protected]

The strategy recommended by Zukowski (http://oai.cwi.nl/oai/asset/14075/14075B.pdf) for integer overflow on values smaller than int64 is to perform the addition on the data type one larger than the input, OR the overflow bit into a result variable during the addition loop, and check the result of that bit after the loop.

For int64, we could use a similar structure to avoid conditional branches, but more checks will be required.

[jordanlewis]

@rafiss pretty sure you took care of this in entirety - please close if you agree.

[rafiss]

Yeah, all arithmetic overflow cases should be handled in vectorized now, see #38967

However, we don't really do projection correctly. See the snippet below. There's another example in this comment but I think we should have a separate issue for this case -- I just made #39189.

[email protected]:60323/defaultdb> create table foo (a int4 primary key);
CREATE TABLE

[email protected]:60323/defaultdb> insert into foo values(1);
INSERT 1

[email protected]:60323/defaultdb> select a+1 from foo;
   ?column?
+------------+
  2
(1 row)

[email protected]:60323/defaultdb> set experimental_vectorize=always;
SET

[email protected]:60323/?> select a+1 from foo;
pq: unable to vectorize execution plan: unable to columnarize render expression "@1 + 1:::INT8": BinaryExpr on int4 and int is unhandled