Added bit and bit varying types

[zachmu]

Fixes #2149

[github-actions]

	Main	PR
covering_index_scan_postgres	554.45/s	525.44/s	-5.3%
index_join_postgres	126.56/s	126.01/s	-0.5%
index_join_scan_postgres	184.67/s	186.05/s	+0.7%
index_scan_postgres	11.37/s	11.46/s	+0.7%
oltp_point_select	2374.52/s	2407.35/s	+1.3%
oltp_read_only	1713.94/s	1721.29/s	+0.4%
select_random_points	111.02/s	112.00/s	+0.8%
select_random_ranges	437.36/s	410.69/s	-6.1%
table_scan_postgres	11.25/s	11.34/s	+0.8%
types_table_scan_postgres	5.06/s	5.25/s	+3.7%

[github-actions]

	Main	PR
Total	42090	42090
Successful	17514	17543
Failures	24576	24547
Partial Successes1	5587	5587

	Main	PR
Successful	41.6108%	41.6797%
Failures	58.3892%	58.3203%

${\color{lightgreen}Progressions (29)}$

aggregates

QUERY: CREATE TEMPORARY TABLE bitwise_test(
  i2 INT2,
  i4 INT4,
  i8 INT8,
  i INTEGER,
  x INT2,
  y BIT(4)
);

bit

QUERY: CREATE TABLE BIT_TABLE(b BIT(11));

QUERY: INSERT INTO BIT_TABLE VALUES (B'00000000000');

QUERY: INSERT INTO BIT_TABLE VALUES (B'11011000000');

QUERY: INSERT INTO BIT_TABLE VALUES (B'01010101010');

QUERY: SELECT * FROM BIT_TABLE;

QUERY: CREATE TABLE VARBIT_TABLE(v BIT VARYING(11));

QUERY: INSERT INTO VARBIT_TABLE VALUES (B'');

QUERY: INSERT INTO VARBIT_TABLE VALUES (B'0');

QUERY: INSERT INTO VARBIT_TABLE VALUES (B'010101');

QUERY: INSERT INTO VARBIT_TABLE VALUES (B'01010101010');

QUERY: SELECT * FROM VARBIT_TABLE;

QUERY: DROP TABLE varbit_table;

QUERY: CREATE TABLE varbit_table (a BIT VARYING(16), b BIT VARYING(16));

QUERY: DROP TABLE varbit_table;

QUERY: DROP TABLE bit_table;

QUERY: CREATE TABLE bit_table (a BIT(16), b BIT(16));

QUERY: DROP TABLE bit_table;

QUERY: CREATE TABLE BIT_SHIFT_TABLE(b BIT(16));

QUERY: INSERT INTO BIT_SHIFT_TABLE VALUES (B'1101100000000000');

QUERY: CREATE TABLE VARBIT_SHIFT_TABLE(v BIT VARYING(20));

QUERY: INSERT INTO VARBIT_SHIFT_TABLE VALUES (B'11011');

QUERY: DROP TABLE BIT_SHIFT_TABLE;

QUERY: DROP TABLE VARBIT_SHIFT_TABLE;

QUERY: CREATE TABLE bit_defaults(
  b1 bit(4) DEFAULT '1001',
  b2 bit(4) DEFAULT B'0101',
  b3 bit varying(5) DEFAULT '1001',
  b4 bit varying(5) DEFAULT B'0101'
);

QUERY: INSERT INTO bit_defaults DEFAULT VALUES;

QUERY: TABLE bit_defaults;

groupingsets

QUERY: create temp table gstest4(id integer, v integer,
                          unhashable_col bit(4), unsortable_col xid);

QUERY: insert into gstest4
values (1,1,b'0000','1'), (2,2,b'0001','1'),
       (3,4,b'0010','2'), (4,8,b'0011','2'),
       (5,16,b'0000','2'), (6,32,b'0001','2'),
       (7,64,b'0010','1'), (8,128,b'0011','1');

Footnotes

1. These are tests that we're marking as Successful, however they do not match the expected output in some way. This is due to small differences, such as different wording on the error messages, or the column names being incorrect while the data itself is correct. ↩

[Hydrocharged]

Type implementations require a bit more diligence with checking Postgres documentation and behavior compared to other feature inclusions. There are a lot of delicate rules that we need to follow that can cause hard-to-debug bugs if we're incorrect in a seemingly unrelated way (such as function overload selection). I'll approve assuming this'll all get updated correctly.

[Hydrocharged]

We can verify if it's correct by connecting it to your local Postgres database and inserting the same query, which we should technically be doing for all of these kinds of queries if we're ever unsure. This should be tested before merging in case it's broken for this case, as bad data is harder to fix once it's in the wild.