2000-11-22 14:37:44 +01:00
|
|
|
--
|
|
|
|
-- BIT types
|
|
|
|
--
|
|
|
|
|
|
|
|
--
|
|
|
|
-- Build tables for testing
|
|
|
|
--
|
|
|
|
|
2001-05-22 18:37:17 +02:00
|
|
|
CREATE TABLE BIT_TABLE(b BIT(11));
|
2000-11-22 14:37:44 +01:00
|
|
|
|
2001-05-22 18:37:17 +02:00
|
|
|
INSERT INTO BIT_TABLE VALUES (B'10'); -- too short
|
|
|
|
INSERT INTO BIT_TABLE VALUES (B'00000000000');
|
|
|
|
INSERT INTO BIT_TABLE VALUES (B'11011000000');
|
|
|
|
INSERT INTO BIT_TABLE VALUES (B'01010101010');
|
|
|
|
INSERT INTO BIT_TABLE VALUES (B'101011111010'); -- too long
|
|
|
|
--INSERT INTO BIT_TABLE VALUES ('X554');
|
|
|
|
--INSERT INTO BIT_TABLE VALUES ('X555');
|
2000-11-22 14:37:44 +01:00
|
|
|
|
2010-11-23 21:27:50 +01:00
|
|
|
SELECT * FROM BIT_TABLE;
|
2000-11-22 14:37:44 +01:00
|
|
|
|
|
|
|
CREATE TABLE VARBIT_TABLE(v BIT VARYING(11));
|
|
|
|
|
|
|
|
INSERT INTO VARBIT_TABLE VALUES (B'');
|
|
|
|
INSERT INTO VARBIT_TABLE VALUES (B'0');
|
|
|
|
INSERT INTO VARBIT_TABLE VALUES (B'010101');
|
|
|
|
INSERT INTO VARBIT_TABLE VALUES (B'01010101010');
|
|
|
|
INSERT INTO VARBIT_TABLE VALUES (B'101011111010'); -- too long
|
|
|
|
--INSERT INTO VARBIT_TABLE VALUES ('X554');
|
|
|
|
--INSERT INTO VARBIT_TABLE VALUES ('X555');
|
2010-11-23 21:27:50 +01:00
|
|
|
SELECT * FROM VARBIT_TABLE;
|
2000-11-22 14:37:44 +01:00
|
|
|
|
|
|
|
|
|
|
|
-- Concatenation
|
|
|
|
SELECT v, b, (v || b) AS concat
|
2010-11-23 21:27:50 +01:00
|
|
|
FROM BIT_TABLE, VARBIT_TABLE
|
2000-11-22 14:37:44 +01:00
|
|
|
ORDER BY 3;
|
|
|
|
|
|
|
|
-- Length
|
|
|
|
SELECT b, length(b) AS lb
|
2001-05-22 18:37:17 +02:00
|
|
|
FROM BIT_TABLE;
|
2000-11-22 14:37:44 +01:00
|
|
|
SELECT v, length(v) AS lv
|
|
|
|
FROM VARBIT_TABLE;
|
|
|
|
|
|
|
|
-- Substring
|
|
|
|
SELECT b,
|
|
|
|
SUBSTRING(b FROM 2 FOR 4) AS sub_2_4,
|
|
|
|
SUBSTRING(b FROM 7 FOR 13) AS sub_7_13,
|
|
|
|
SUBSTRING(b FROM 6) AS sub_6
|
2001-05-22 18:37:17 +02:00
|
|
|
FROM BIT_TABLE;
|
2000-11-22 14:37:44 +01:00
|
|
|
SELECT v,
|
|
|
|
SUBSTRING(v FROM 2 FOR 4) AS sub_2_4,
|
|
|
|
SUBSTRING(v FROM 7 FOR 13) AS sub_7_13,
|
|
|
|
SUBSTRING(v FROM 6) AS sub_6
|
|
|
|
FROM VARBIT_TABLE;
|
|
|
|
|
Fix integer-overflow corner cases in substring() functions.
If the substring start index and length overflow when added together,
substring() misbehaved, either throwing a bogus "negative substring
length" error on a case that should succeed, or failing to complain that
a negative length is negative (and instead returning the whole string,
in most cases). Unsurprisingly, the text, bytea, and bit variants of
the function all had this issue. Rearrange the logic to ensure that
negative lengths are always rejected, and add an overflow check to
handle the other case.
Also install similar guards into detoast_attr_slice() (nee
heap_tuple_untoast_attr_slice()), since it's far from clear that
no other code paths leading to that function could pass it values
that would overflow.
Patch by myself and Pavel Stehule, per bug #16804 from Rafi Shamim.
Back-patch to v11. While these bugs are old, the common/int.h
infrastructure for overflow-detecting arithmetic didn't exist before
commit 4d6ad3125, and it doesn't seem like these misbehaviors are bad
enough to justify developing a standalone fix for the older branches.
Discussion: https://postgr.es/m/16804-f4eeeb6c11ba71d4@postgresql.org
2021-01-05 00:32:40 +01:00
|
|
|
-- test overflow cases
|
|
|
|
SELECT SUBSTRING('01010101'::bit(8) FROM 2 FOR 2147483646) AS "1010101";
|
|
|
|
SELECT SUBSTRING('01010101'::bit(8) FROM -10 FOR 2147483646) AS "01010101";
|
|
|
|
SELECT SUBSTRING('01010101'::bit(8) FROM -10 FOR -2147483646) AS "error";
|
|
|
|
SELECT SUBSTRING('01010101'::varbit FROM 2 FOR 2147483646) AS "1010101";
|
|
|
|
SELECT SUBSTRING('01010101'::varbit FROM -10 FOR 2147483646) AS "01010101";
|
|
|
|
SELECT SUBSTRING('01010101'::varbit FROM -10 FOR -2147483646) AS "error";
|
|
|
|
|
2000-11-22 14:37:44 +01:00
|
|
|
--- Bit operations
|
|
|
|
DROP TABLE varbit_table;
|
|
|
|
CREATE TABLE varbit_table (a BIT VARYING(16), b BIT VARYING(16));
|
|
|
|
COPY varbit_table FROM stdin;
|
|
|
|
X0F X10
|
|
|
|
X1F X11
|
|
|
|
X2F X12
|
|
|
|
X3F X13
|
|
|
|
X8F X04
|
|
|
|
X000F X0010
|
|
|
|
X0123 XFFFF
|
|
|
|
X2468 X2468
|
|
|
|
XFA50 X05AF
|
|
|
|
X1234 XFFF5
|
|
|
|
\.
|
|
|
|
|
2010-11-23 21:27:50 +01:00
|
|
|
SELECT a, b, ~a AS "~ a", a & b AS "a & b",
|
2000-11-22 14:37:44 +01:00
|
|
|
a | b AS "a | b", a # b AS "a # b" FROM varbit_table;
|
|
|
|
SELECT a,b,a<b AS "a<b",a<=b AS "a<=b",a=b AS "a=b",
|
|
|
|
a>=b AS "a>=b",a>b AS "a>b",a<>b AS "a<>b" FROM varbit_table;
|
|
|
|
SELECT a,a<<4 AS "a<<4",b,b>>2 AS "b>>2" FROM varbit_table;
|
|
|
|
|
|
|
|
DROP TABLE varbit_table;
|
|
|
|
|
|
|
|
--- Bit operations
|
2001-05-22 18:37:17 +02:00
|
|
|
DROP TABLE bit_table;
|
|
|
|
CREATE TABLE bit_table (a BIT(16), b BIT(16));
|
|
|
|
COPY bit_table FROM stdin;
|
|
|
|
X0F00 X1000
|
|
|
|
X1F00 X1100
|
|
|
|
X2F00 X1200
|
|
|
|
X3F00 X1300
|
|
|
|
X8F00 X0400
|
2000-11-22 14:37:44 +01:00
|
|
|
X000F X0010
|
|
|
|
X0123 XFFFF
|
|
|
|
X2468 X2468
|
|
|
|
XFA50 X05AF
|
|
|
|
X1234 XFFF5
|
|
|
|
\.
|
|
|
|
|
2010-11-23 21:27:50 +01:00
|
|
|
SELECT a,b,~a AS "~ a",a & b AS "a & b",
|
2001-05-22 18:37:17 +02:00
|
|
|
a|b AS "a | b", a # b AS "a # b" FROM bit_table;
|
2000-11-22 14:37:44 +01:00
|
|
|
SELECT a,b,a<b AS "a<b",a<=b AS "a<=b",a=b AS "a=b",
|
2001-05-22 18:37:17 +02:00
|
|
|
a>=b AS "a>=b",a>b AS "a>b",a<>b AS "a<>b" FROM bit_table;
|
|
|
|
SELECT a,a<<4 AS "a<<4",b,b>>2 AS "b>>2" FROM bit_table;
|
2000-11-22 14:37:44 +01:00
|
|
|
|
2001-05-22 18:37:17 +02:00
|
|
|
DROP TABLE bit_table;
|
2000-11-22 14:37:44 +01:00
|
|
|
|
|
|
|
|
|
|
|
-- The following should fail
|
|
|
|
select B'001' & B'10';
|
|
|
|
select B'0111' | B'011';
|
|
|
|
select B'0010' # B'011101';
|
|
|
|
|
|
|
|
-- More position tests, checking all the boundary cases
|
|
|
|
SELECT POSITION(B'1010' IN B'0000101'); -- 0
|
|
|
|
SELECT POSITION(B'1010' IN B'00001010'); -- 5
|
|
|
|
SELECT POSITION(B'1010' IN B'00000101'); -- 0
|
|
|
|
SELECT POSITION(B'1010' IN B'000001010'); -- 6
|
|
|
|
|
|
|
|
SELECT POSITION(B'' IN B'00001010'); -- 1
|
|
|
|
SELECT POSITION(B'0' IN B''); -- 0
|
|
|
|
SELECT POSITION(B'' IN B''); -- 0
|
|
|
|
SELECT POSITION(B'101101' IN B'001011011011011000'); -- 3
|
|
|
|
SELECT POSITION(B'10110110' IN B'001011011011010'); -- 3
|
|
|
|
SELECT POSITION(B'1011011011011' IN B'001011011011011'); -- 3
|
|
|
|
SELECT POSITION(B'1011011011011' IN B'00001011011011011'); -- 5
|
|
|
|
|
|
|
|
SELECT POSITION(B'11101011' IN B'11101011'); -- 1
|
|
|
|
SELECT POSITION(B'11101011' IN B'011101011'); -- 2
|
|
|
|
SELECT POSITION(B'11101011' IN B'00011101011'); -- 4
|
|
|
|
SELECT POSITION(B'11101011' IN B'0000011101011'); -- 6
|
|
|
|
|
|
|
|
SELECT POSITION(B'111010110' IN B'111010110'); -- 1
|
|
|
|
SELECT POSITION(B'111010110' IN B'0111010110'); -- 2
|
|
|
|
SELECT POSITION(B'111010110' IN B'000111010110'); -- 4
|
|
|
|
SELECT POSITION(B'111010110' IN B'00000111010110'); -- 6
|
|
|
|
|
|
|
|
SELECT POSITION(B'111010110' IN B'11101011'); -- 0
|
|
|
|
SELECT POSITION(B'111010110' IN B'011101011'); -- 0
|
|
|
|
SELECT POSITION(B'111010110' IN B'00011101011'); -- 0
|
|
|
|
SELECT POSITION(B'111010110' IN B'0000011101011'); -- 0
|
|
|
|
|
|
|
|
SELECT POSITION(B'111010110' IN B'111010110'); -- 1
|
|
|
|
SELECT POSITION(B'111010110' IN B'0111010110'); -- 2
|
|
|
|
SELECT POSITION(B'111010110' IN B'000111010110'); -- 4
|
|
|
|
SELECT POSITION(B'111010110' IN B'00000111010110'); -- 6
|
|
|
|
|
|
|
|
SELECT POSITION(B'111010110' IN B'000001110101111101011'); -- 0
|
|
|
|
SELECT POSITION(B'111010110' IN B'0000001110101111101011'); -- 0
|
|
|
|
SELECT POSITION(B'111010110' IN B'000000001110101111101011'); -- 0
|
|
|
|
SELECT POSITION(B'111010110' IN B'00000000001110101111101011'); -- 0
|
|
|
|
|
|
|
|
SELECT POSITION(B'111010110' IN B'0000011101011111010110'); -- 14
|
|
|
|
SELECT POSITION(B'111010110' IN B'00000011101011111010110'); -- 15
|
|
|
|
SELECT POSITION(B'111010110' IN B'0000000011101011111010110'); -- 17
|
|
|
|
SELECT POSITION(B'111010110' IN B'000000000011101011111010110'); -- 19
|
|
|
|
|
|
|
|
SELECT POSITION(B'000000000011101011111010110' IN B'000000000011101011111010110'); -- 1
|
|
|
|
SELECT POSITION(B'00000000011101011111010110' IN B'000000000011101011111010110'); -- 2
|
|
|
|
SELECT POSITION(B'0000000000011101011111010110' IN B'000000000011101011111010110'); -- 0
|
|
|
|
|
|
|
|
|
|
|
|
-- Shifting
|
|
|
|
|
2001-05-22 18:37:17 +02:00
|
|
|
CREATE TABLE BIT_SHIFT_TABLE(b BIT(16));
|
|
|
|
INSERT INTO BIT_SHIFT_TABLE VALUES (B'1101100000000000');
|
|
|
|
INSERT INTO BIT_SHIFT_TABLE SELECT b>>1 FROM BIT_SHIFT_TABLE;
|
|
|
|
INSERT INTO BIT_SHIFT_TABLE SELECT b>>2 FROM BIT_SHIFT_TABLE;
|
|
|
|
INSERT INTO BIT_SHIFT_TABLE SELECT b>>4 FROM BIT_SHIFT_TABLE;
|
|
|
|
INSERT INTO BIT_SHIFT_TABLE SELECT b>>8 FROM BIT_SHIFT_TABLE;
|
|
|
|
SELECT POSITION(B'1101' IN b),
|
2000-11-22 14:37:44 +01:00
|
|
|
POSITION(B'11011' IN b),
|
2010-11-23 21:27:50 +01:00
|
|
|
b
|
2001-05-22 18:37:17 +02:00
|
|
|
FROM BIT_SHIFT_TABLE ;
|
Fix failure to zero-pad the result of bitshiftright().
If the bitstring length is not a multiple of 8, we'd shift the
rightmost bits into the pad space, which must be zeroes --- bit_cmp,
for one, depends on that. This'd lead to the result failing to
compare equal to what it should compare equal to, as reported in
bug #16013 from Daryl Waycott.
This is, if memory serves, not the first such bug in the bitstring
functions. In hopes of making it the last one, do a bit more work
than minimally necessary to fix the bug:
* Add assertion checks to bit_out() and varbit_out() to complain if
they are given incorrectly-padded input. This will improve the
odds that manual testing of any new patch finds problems.
* Encapsulate the padding-related logic in macros to make it
easier to use.
Also, remove unnecessary padding logic from bit_or() and bitxor().
Somebody had already noted that we need not re-pad the result of
bit_and() since the inputs are required to be the same length,
but failed to extrapolate that to the other two.
Also, move a comment block that once was near the head of varbit.c
(but people kept putting other stuff in front of it), to put it in
the header block.
Note for the release notes: if anyone has inconsistent data as a
result of saving the output of bitshiftright() in a table, it's
possible to fix it with something like
UPDATE mytab SET bitcol = ~(~bitcol) WHERE bitcol != ~(~bitcol);
This has been broken since day one, so back-patch to all supported
branches.
Discussion: https://postgr.es/m/16013-c2765b6996aacae9@postgresql.org
2019-09-22 23:45:59 +02:00
|
|
|
SELECT b, b >> 1 AS bsr, b << 1 AS bsl
|
|
|
|
FROM BIT_SHIFT_TABLE ;
|
2019-10-04 16:34:21 +02:00
|
|
|
SELECT b, b >> 8 AS bsr8, b << 8 AS bsl8
|
|
|
|
FROM BIT_SHIFT_TABLE ;
|
Fix failure to zero-pad the result of bitshiftright().
If the bitstring length is not a multiple of 8, we'd shift the
rightmost bits into the pad space, which must be zeroes --- bit_cmp,
for one, depends on that. This'd lead to the result failing to
compare equal to what it should compare equal to, as reported in
bug #16013 from Daryl Waycott.
This is, if memory serves, not the first such bug in the bitstring
functions. In hopes of making it the last one, do a bit more work
than minimally necessary to fix the bug:
* Add assertion checks to bit_out() and varbit_out() to complain if
they are given incorrectly-padded input. This will improve the
odds that manual testing of any new patch finds problems.
* Encapsulate the padding-related logic in macros to make it
easier to use.
Also, remove unnecessary padding logic from bit_or() and bitxor().
Somebody had already noted that we need not re-pad the result of
bit_and() since the inputs are required to be the same length,
but failed to extrapolate that to the other two.
Also, move a comment block that once was near the head of varbit.c
(but people kept putting other stuff in front of it), to put it in
the header block.
Note for the release notes: if anyone has inconsistent data as a
result of saving the output of bitshiftright() in a table, it's
possible to fix it with something like
UPDATE mytab SET bitcol = ~(~bitcol) WHERE bitcol != ~(~bitcol);
This has been broken since day one, so back-patch to all supported
branches.
Discussion: https://postgr.es/m/16013-c2765b6996aacae9@postgresql.org
2019-09-22 23:45:59 +02:00
|
|
|
SELECT b::bit(15), b::bit(15) >> 1 AS bsr, b::bit(15) << 1 AS bsl
|
|
|
|
FROM BIT_SHIFT_TABLE ;
|
2019-10-04 16:34:21 +02:00
|
|
|
SELECT b::bit(15), b::bit(15) >> 8 AS bsr8, b::bit(15) << 8 AS bsl8
|
|
|
|
FROM BIT_SHIFT_TABLE ;
|
2000-11-22 14:37:44 +01:00
|
|
|
|
|
|
|
|
2001-05-22 18:37:17 +02:00
|
|
|
CREATE TABLE VARBIT_SHIFT_TABLE(v BIT VARYING(20));
|
2000-11-22 14:37:44 +01:00
|
|
|
INSERT INTO VARBIT_SHIFT_TABLE VALUES (B'11011');
|
2001-05-22 18:37:17 +02:00
|
|
|
INSERT INTO VARBIT_SHIFT_TABLE SELECT CAST(v || B'0' AS BIT VARYING(6)) >>1 FROM VARBIT_SHIFT_TABLE;
|
|
|
|
INSERT INTO VARBIT_SHIFT_TABLE SELECT CAST(v || B'00' AS BIT VARYING(8)) >>2 FROM VARBIT_SHIFT_TABLE;
|
|
|
|
INSERT INTO VARBIT_SHIFT_TABLE SELECT CAST(v || B'0000' AS BIT VARYING(12)) >>4 FROM VARBIT_SHIFT_TABLE;
|
|
|
|
INSERT INTO VARBIT_SHIFT_TABLE SELECT CAST(v || B'00000000' AS BIT VARYING(20)) >>8 FROM VARBIT_SHIFT_TABLE;
|
2000-11-22 14:37:44 +01:00
|
|
|
SELECT POSITION(B'1101' IN v),
|
|
|
|
POSITION(B'11011' IN v),
|
2010-11-23 21:27:50 +01:00
|
|
|
v
|
2000-11-22 14:37:44 +01:00
|
|
|
FROM VARBIT_SHIFT_TABLE ;
|
Fix failure to zero-pad the result of bitshiftright().
If the bitstring length is not a multiple of 8, we'd shift the
rightmost bits into the pad space, which must be zeroes --- bit_cmp,
for one, depends on that. This'd lead to the result failing to
compare equal to what it should compare equal to, as reported in
bug #16013 from Daryl Waycott.
This is, if memory serves, not the first such bug in the bitstring
functions. In hopes of making it the last one, do a bit more work
than minimally necessary to fix the bug:
* Add assertion checks to bit_out() and varbit_out() to complain if
they are given incorrectly-padded input. This will improve the
odds that manual testing of any new patch finds problems.
* Encapsulate the padding-related logic in macros to make it
easier to use.
Also, remove unnecessary padding logic from bit_or() and bitxor().
Somebody had already noted that we need not re-pad the result of
bit_and() since the inputs are required to be the same length,
but failed to extrapolate that to the other two.
Also, move a comment block that once was near the head of varbit.c
(but people kept putting other stuff in front of it), to put it in
the header block.
Note for the release notes: if anyone has inconsistent data as a
result of saving the output of bitshiftright() in a table, it's
possible to fix it with something like
UPDATE mytab SET bitcol = ~(~bitcol) WHERE bitcol != ~(~bitcol);
This has been broken since day one, so back-patch to all supported
branches.
Discussion: https://postgr.es/m/16013-c2765b6996aacae9@postgresql.org
2019-09-22 23:45:59 +02:00
|
|
|
SELECT v, v >> 1 AS vsr, v << 1 AS vsl
|
|
|
|
FROM VARBIT_SHIFT_TABLE ;
|
2019-10-04 16:34:21 +02:00
|
|
|
SELECT v, v >> 8 AS vsr8, v << 8 AS vsl8
|
|
|
|
FROM VARBIT_SHIFT_TABLE ;
|
2000-11-22 14:37:44 +01:00
|
|
|
|
2001-05-22 18:37:17 +02:00
|
|
|
DROP TABLE BIT_SHIFT_TABLE;
|
2000-11-22 14:37:44 +01:00
|
|
|
DROP TABLE VARBIT_SHIFT_TABLE;
|
2010-01-25 21:55:32 +01:00
|
|
|
|
|
|
|
-- Get/Set bit
|
|
|
|
SELECT get_bit(B'0101011000100', 10);
|
|
|
|
SELECT set_bit(B'0101011000100100', 15, 1);
|
|
|
|
SELECT set_bit(B'0101011000100100', 16, 1); -- fail
|
|
|
|
|
|
|
|
-- Overlay
|
|
|
|
SELECT overlay(B'0101011100' placing '001' from 2 for 3);
|
|
|
|
SELECT overlay(B'0101011100' placing '101' from 6);
|
|
|
|
SELECT overlay(B'0101011100' placing '001' from 11);
|
|
|
|
SELECT overlay(B'0101011100' placing '001' from 20);
|
Remove ruleutils.c's special case for BIT [VARYING] literals.
Up to now, get_const_expr() insisted on prefixing BIT and VARBIT
literals with 'B'. That's not really necessary, because we always
append explicit-cast syntax to identify the constant's type.
Moreover, it's subtly wrong for VARBIT, because the parser will
interpret B'...' as '...'::"bit"; see make_const() which explicitly
assigns type BITOID for a T_BitString literal. So what had been
a simple VARBIT literal is reconstructed as ('...'::"bit")::varbit,
which is not the same thing, at least not before constant folding.
This results in odd differences after dump/restore, as complained
of by the patch submitter, and it could result in actual failures in
partitioning or inheritance DDL operations (see commit 542320c2b,
which repaired similar misbehaviors for some other data types).
Fixing it is pretty easy: just remove the special case and let the
default code path handle these types. We could have kept the special
case for BIT only, but there seems little point in that.
Like the previous patch, I judge that back-patching this into stable
branches wouldn't be a good idea. However, it seems not quite too
late for v11, so let's fix it there.
Paul Guo, reviewed by Davy Machado and John Naylor, minor adjustments
by me
Discussion: https://postgr.es/m/CABQrizdTra=2JEqA6+Ms1D1k1Kqw+aiBBhC9TreuZRX2JzxLAA@mail.gmail.com
2018-09-11 22:32:12 +02:00
|
|
|
|
2021-03-23 08:45:51 +01:00
|
|
|
-- bit_count
|
|
|
|
SELECT bit_count(B'0101011100'::bit(10));
|
|
|
|
SELECT bit_count(B'1111111111'::bit(10));
|
|
|
|
|
Remove ruleutils.c's special case for BIT [VARYING] literals.
Up to now, get_const_expr() insisted on prefixing BIT and VARBIT
literals with 'B'. That's not really necessary, because we always
append explicit-cast syntax to identify the constant's type.
Moreover, it's subtly wrong for VARBIT, because the parser will
interpret B'...' as '...'::"bit"; see make_const() which explicitly
assigns type BITOID for a T_BitString literal. So what had been
a simple VARBIT literal is reconstructed as ('...'::"bit")::varbit,
which is not the same thing, at least not before constant folding.
This results in odd differences after dump/restore, as complained
of by the patch submitter, and it could result in actual failures in
partitioning or inheritance DDL operations (see commit 542320c2b,
which repaired similar misbehaviors for some other data types).
Fixing it is pretty easy: just remove the special case and let the
default code path handle these types. We could have kept the special
case for BIT only, but there seems little point in that.
Like the previous patch, I judge that back-patching this into stable
branches wouldn't be a good idea. However, it seems not quite too
late for v11, so let's fix it there.
Paul Guo, reviewed by Davy Machado and John Naylor, minor adjustments
by me
Discussion: https://postgr.es/m/CABQrizdTra=2JEqA6+Ms1D1k1Kqw+aiBBhC9TreuZRX2JzxLAA@mail.gmail.com
2018-09-11 22:32:12 +02:00
|
|
|
-- This table is intentionally left around to exercise pg_dump/pg_upgrade
|
|
|
|
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'
|
|
|
|
);
|
|
|
|
\d bit_defaults
|
|
|
|
INSERT INTO bit_defaults DEFAULT VALUES;
|
|
|
|
TABLE bit_defaults;
|