2000-01-05 18:32:18 +01:00
|
|
|
--
|
|
|
|
-- CONSTRAINTS
|
|
|
|
-- Constraints can be specified with:
|
|
|
|
-- - DEFAULT clause
|
|
|
|
-- - CHECK clauses
|
|
|
|
-- - PRIMARY KEY clauses
|
|
|
|
-- - UNIQUE clauses
|
2009-12-07 06:22:23 +01:00
|
|
|
-- - EXCLUDE clauses
|
2000-01-05 18:32:18 +01:00
|
|
|
--
|
2021-12-20 20:06:15 +01:00
|
|
|
-- directory paths are passed to us in environment variables
|
|
|
|
\getenv abs_srcdir PG_ABS_SRCDIR
|
2000-01-05 18:32:18 +01:00
|
|
|
--
|
|
|
|
-- DEFAULT syntax
|
|
|
|
--
|
|
|
|
CREATE TABLE DEFAULT_TBL (i int DEFAULT 100,
|
1997-12-05 01:01:22 +01:00
|
|
|
x text DEFAULT 'vadim', f float8 DEFAULT 123.456);
|
2000-01-05 18:32:18 +01:00
|
|
|
INSERT INTO DEFAULT_TBL VALUES (1, 'thomas', 57.0613);
|
|
|
|
INSERT INTO DEFAULT_TBL VALUES (1, 'bruce');
|
|
|
|
INSERT INTO DEFAULT_TBL (i, f) VALUES (2, 987.654);
|
|
|
|
INSERT INTO DEFAULT_TBL (x) VALUES ('marc');
|
|
|
|
INSERT INTO DEFAULT_TBL VALUES (3, null, 1.0);
|
2020-12-15 21:54:06 +01:00
|
|
|
SELECT * FROM DEFAULT_TBL;
|
|
|
|
i | x | f
|
|
|
|
-----+--------+---------
|
|
|
|
1 | thomas | 57.0613
|
|
|
|
1 | bruce | 123.456
|
|
|
|
2 | vadim | 987.654
|
|
|
|
100 | marc | 123.456
|
|
|
|
3 | | 1
|
1997-10-17 11:59:09 +02:00
|
|
|
(5 rows)
|
1997-09-16 18:17:19 +02:00
|
|
|
|
2000-01-05 18:32:18 +01:00
|
|
|
CREATE SEQUENCE DEFAULT_SEQ;
|
|
|
|
CREATE TABLE DEFAULTEXPR_TBL (i1 int DEFAULT 100 + (200-199) * 2,
|
1997-12-05 01:01:22 +01:00
|
|
|
i2 int DEFAULT nextval('default_seq'));
|
2000-01-05 18:32:18 +01:00
|
|
|
INSERT INTO DEFAULTEXPR_TBL VALUES (-1, -2);
|
|
|
|
INSERT INTO DEFAULTEXPR_TBL (i1) VALUES (-3);
|
|
|
|
INSERT INTO DEFAULTEXPR_TBL (i2) VALUES (-4);
|
|
|
|
INSERT INTO DEFAULTEXPR_TBL (i2) VALUES (NULL);
|
2020-12-15 21:54:06 +01:00
|
|
|
SELECT * FROM DEFAULTEXPR_TBL;
|
|
|
|
i1 | i2
|
|
|
|
-----+----
|
|
|
|
-1 | -2
|
|
|
|
-3 | 1
|
|
|
|
102 | -4
|
|
|
|
102 |
|
1997-09-16 18:17:19 +02:00
|
|
|
(4 rows)
|
|
|
|
|
2000-01-05 18:32:18 +01:00
|
|
|
-- syntax errors
|
|
|
|
-- test for extraneous comma
|
|
|
|
CREATE TABLE error_tbl (i int DEFAULT (100, ));
|
2006-03-14 23:48:25 +01:00
|
|
|
ERROR: syntax error at or near ")"
|
2004-03-14 05:25:18 +01:00
|
|
|
LINE 1: CREATE TABLE error_tbl (i int DEFAULT (100, ));
|
2004-05-11 00:44:49 +02:00
|
|
|
^
|
2000-01-05 18:32:18 +01:00
|
|
|
-- this will fail because gram.y uses b_expr not a_expr for defaults,
|
|
|
|
-- to avoid a shift/reduce conflict that arises from NOT NULL being
|
|
|
|
-- part of the column definition syntax:
|
|
|
|
CREATE TABLE error_tbl (b1 bool DEFAULT 1 IN (1, 2));
|
2006-03-14 23:48:25 +01:00
|
|
|
ERROR: syntax error at or near "IN"
|
2004-03-14 05:25:18 +01:00
|
|
|
LINE 1: CREATE TABLE error_tbl (b1 bool DEFAULT 1 IN (1, 2));
|
|
|
|
^
|
2000-01-05 18:32:18 +01:00
|
|
|
-- this should work, however:
|
|
|
|
CREATE TABLE error_tbl (b1 bool DEFAULT (1 IN (1, 2)));
|
|
|
|
DROP TABLE error_tbl;
|
|
|
|
--
|
|
|
|
-- CHECK syntax
|
|
|
|
--
|
|
|
|
CREATE TABLE CHECK_TBL (x int,
|
1997-12-05 01:01:22 +01:00
|
|
|
CONSTRAINT CHECK_CON CHECK (x > 3));
|
2000-01-05 18:32:18 +01:00
|
|
|
INSERT INTO CHECK_TBL VALUES (5);
|
|
|
|
INSERT INTO CHECK_TBL VALUES (4);
|
|
|
|
INSERT INTO CHECK_TBL VALUES (3);
|
2003-09-25 17:48:17 +02:00
|
|
|
ERROR: new row for relation "check_tbl" violates check constraint "check_con"
|
2011-11-29 21:02:10 +01:00
|
|
|
DETAIL: Failing row contains (3).
|
2000-01-05 18:32:18 +01:00
|
|
|
INSERT INTO CHECK_TBL VALUES (2);
|
2003-09-25 17:48:17 +02:00
|
|
|
ERROR: new row for relation "check_tbl" violates check constraint "check_con"
|
2011-11-29 21:02:10 +01:00
|
|
|
DETAIL: Failing row contains (2).
|
2000-01-05 18:32:18 +01:00
|
|
|
INSERT INTO CHECK_TBL VALUES (6);
|
|
|
|
INSERT INTO CHECK_TBL VALUES (1);
|
2003-09-25 17:48:17 +02:00
|
|
|
ERROR: new row for relation "check_tbl" violates check constraint "check_con"
|
2011-11-29 21:02:10 +01:00
|
|
|
DETAIL: Failing row contains (1).
|
2020-12-15 21:54:06 +01:00
|
|
|
SELECT * FROM CHECK_TBL;
|
|
|
|
x
|
|
|
|
---
|
|
|
|
5
|
|
|
|
4
|
|
|
|
6
|
1997-12-05 01:01:22 +01:00
|
|
|
(3 rows)
|
|
|
|
|
2000-01-05 18:32:18 +01:00
|
|
|
CREATE SEQUENCE CHECK_SEQ;
|
|
|
|
CREATE TABLE CHECK2_TBL (x int, y text, z int,
|
1997-12-05 01:01:22 +01:00
|
|
|
CONSTRAINT SEQUENCE_CON
|
|
|
|
CHECK (x > 3 and y <> 'check failed' and z < 8));
|
2000-01-05 18:32:18 +01:00
|
|
|
INSERT INTO CHECK2_TBL VALUES (4, 'check ok', -2);
|
|
|
|
INSERT INTO CHECK2_TBL VALUES (1, 'x check failed', -2);
|
2003-09-25 17:48:17 +02:00
|
|
|
ERROR: new row for relation "check2_tbl" violates check constraint "sequence_con"
|
2011-11-29 21:02:10 +01:00
|
|
|
DETAIL: Failing row contains (1, x check failed, -2).
|
2000-01-05 18:32:18 +01:00
|
|
|
INSERT INTO CHECK2_TBL VALUES (5, 'z check failed', 10);
|
2003-09-25 17:48:17 +02:00
|
|
|
ERROR: new row for relation "check2_tbl" violates check constraint "sequence_con"
|
2011-11-29 21:02:10 +01:00
|
|
|
DETAIL: Failing row contains (5, z check failed, 10).
|
2000-01-05 18:32:18 +01:00
|
|
|
INSERT INTO CHECK2_TBL VALUES (0, 'check failed', -2);
|
2003-09-25 17:48:17 +02:00
|
|
|
ERROR: new row for relation "check2_tbl" violates check constraint "sequence_con"
|
2011-11-29 21:02:10 +01:00
|
|
|
DETAIL: Failing row contains (0, check failed, -2).
|
2000-01-05 18:32:18 +01:00
|
|
|
INSERT INTO CHECK2_TBL VALUES (6, 'check failed', 11);
|
2003-09-25 17:48:17 +02:00
|
|
|
ERROR: new row for relation "check2_tbl" violates check constraint "sequence_con"
|
2011-11-29 21:02:10 +01:00
|
|
|
DETAIL: Failing row contains (6, check failed, 11).
|
2000-01-05 18:32:18 +01:00
|
|
|
INSERT INTO CHECK2_TBL VALUES (7, 'check ok', 7);
|
2020-12-15 21:54:06 +01:00
|
|
|
SELECT * from CHECK2_TBL;
|
|
|
|
x | y | z
|
|
|
|
---+----------+----
|
|
|
|
4 | check ok | -2
|
|
|
|
7 | check ok | 7
|
1997-12-05 01:01:22 +01:00
|
|
|
(2 rows)
|
|
|
|
|
2000-01-05 18:32:18 +01:00
|
|
|
--
|
|
|
|
-- Check constraints on INSERT
|
|
|
|
--
|
|
|
|
CREATE SEQUENCE INSERT_SEQ;
|
|
|
|
CREATE TABLE INSERT_TBL (x INT DEFAULT nextval('insert_seq'),
|
2000-01-16 20:57:48 +01:00
|
|
|
y TEXT DEFAULT '-NULL-',
|
|
|
|
z INT DEFAULT -1 * currval('insert_seq'),
|
Apply table and domain CHECK constraints in name order.
Previously, CHECK constraints of the same scope were checked in whatever
order they happened to be read from pg_constraint. (Usually, but not
reliably, this would be creation order for domain constraints and reverse
creation order for table constraints, because of differing implementation
details.) Nondeterministic results of this sort are problematic at least
for testing purposes, and in discussion it was agreed to be a violation of
the principle of least astonishment. Therefore, borrow the principle
already established for triggers, and apply such checks in name order
(using strcmp() sort rules). This lets users control the check order
if they have a mind to.
Domain CHECK constraints still follow the rule of checking lower nested
domains' constraints first; the name sort only applies to multiple
constraints attached to the same domain.
In passing, I failed to resist the temptation to wordsmith a bit in
create_domain.sgml.
Apply to HEAD only, since this could result in a behavioral change in
existing applications, and the potential regression test failures have
not actually been observed in our buildfarm.
2015-03-23 21:59:29 +01:00
|
|
|
CONSTRAINT INSERT_TBL_CON CHECK (x >= 3 AND y <> 'check failed' AND x < 8),
|
2000-01-16 20:57:48 +01:00
|
|
|
CHECK (x + z = 0));
|
2000-01-05 18:32:18 +01:00
|
|
|
INSERT INTO INSERT_TBL(x,z) VALUES (2, -2);
|
Apply table and domain CHECK constraints in name order.
Previously, CHECK constraints of the same scope were checked in whatever
order they happened to be read from pg_constraint. (Usually, but not
reliably, this would be creation order for domain constraints and reverse
creation order for table constraints, because of differing implementation
details.) Nondeterministic results of this sort are problematic at least
for testing purposes, and in discussion it was agreed to be a violation of
the principle of least astonishment. Therefore, borrow the principle
already established for triggers, and apply such checks in name order
(using strcmp() sort rules). This lets users control the check order
if they have a mind to.
Domain CHECK constraints still follow the rule of checking lower nested
domains' constraints first; the name sort only applies to multiple
constraints attached to the same domain.
In passing, I failed to resist the temptation to wordsmith a bit in
create_domain.sgml.
Apply to HEAD only, since this could result in a behavioral change in
existing applications, and the potential regression test failures have
not actually been observed in our buildfarm.
2015-03-23 21:59:29 +01:00
|
|
|
ERROR: new row for relation "insert_tbl" violates check constraint "insert_tbl_con"
|
2011-11-29 21:02:10 +01:00
|
|
|
DETAIL: Failing row contains (2, -NULL-, -2).
|
2020-12-15 21:54:06 +01:00
|
|
|
SELECT * FROM INSERT_TBL;
|
|
|
|
x | y | z
|
|
|
|
---+---+---
|
1997-08-28 06:49:34 +02:00
|
|
|
(0 rows)
|
|
|
|
|
2000-01-05 18:32:18 +01:00
|
|
|
SELECT 'one' AS one, nextval('insert_seq');
|
|
|
|
one | nextval
|
|
|
|
-----+---------
|
|
|
|
one | 1
|
1997-08-28 06:49:34 +02:00
|
|
|
(1 row)
|
|
|
|
|
2000-01-05 18:32:18 +01:00
|
|
|
INSERT INTO INSERT_TBL(y) VALUES ('Y');
|
Apply table and domain CHECK constraints in name order.
Previously, CHECK constraints of the same scope were checked in whatever
order they happened to be read from pg_constraint. (Usually, but not
reliably, this would be creation order for domain constraints and reverse
creation order for table constraints, because of differing implementation
details.) Nondeterministic results of this sort are problematic at least
for testing purposes, and in discussion it was agreed to be a violation of
the principle of least astonishment. Therefore, borrow the principle
already established for triggers, and apply such checks in name order
(using strcmp() sort rules). This lets users control the check order
if they have a mind to.
Domain CHECK constraints still follow the rule of checking lower nested
domains' constraints first; the name sort only applies to multiple
constraints attached to the same domain.
In passing, I failed to resist the temptation to wordsmith a bit in
create_domain.sgml.
Apply to HEAD only, since this could result in a behavioral change in
existing applications, and the potential regression test failures have
not actually been observed in our buildfarm.
2015-03-23 21:59:29 +01:00
|
|
|
ERROR: new row for relation "insert_tbl" violates check constraint "insert_tbl_con"
|
2011-11-29 21:02:10 +01:00
|
|
|
DETAIL: Failing row contains (2, Y, -2).
|
2000-01-05 18:32:18 +01:00
|
|
|
INSERT INTO INSERT_TBL(y) VALUES ('Y');
|
|
|
|
INSERT INTO INSERT_TBL(x,z) VALUES (1, -2);
|
2004-06-10 19:56:03 +02:00
|
|
|
ERROR: new row for relation "insert_tbl" violates check constraint "insert_tbl_check"
|
2011-11-29 21:02:10 +01:00
|
|
|
DETAIL: Failing row contains (1, -NULL-, -2).
|
2000-01-05 18:32:18 +01:00
|
|
|
INSERT INTO INSERT_TBL(z,x) VALUES (-7, 7);
|
|
|
|
INSERT INTO INSERT_TBL VALUES (5, 'check failed', -5);
|
Apply table and domain CHECK constraints in name order.
Previously, CHECK constraints of the same scope were checked in whatever
order they happened to be read from pg_constraint. (Usually, but not
reliably, this would be creation order for domain constraints and reverse
creation order for table constraints, because of differing implementation
details.) Nondeterministic results of this sort are problematic at least
for testing purposes, and in discussion it was agreed to be a violation of
the principle of least astonishment. Therefore, borrow the principle
already established for triggers, and apply such checks in name order
(using strcmp() sort rules). This lets users control the check order
if they have a mind to.
Domain CHECK constraints still follow the rule of checking lower nested
domains' constraints first; the name sort only applies to multiple
constraints attached to the same domain.
In passing, I failed to resist the temptation to wordsmith a bit in
create_domain.sgml.
Apply to HEAD only, since this could result in a behavioral change in
existing applications, and the potential regression test failures have
not actually been observed in our buildfarm.
2015-03-23 21:59:29 +01:00
|
|
|
ERROR: new row for relation "insert_tbl" violates check constraint "insert_tbl_con"
|
2011-11-29 21:02:10 +01:00
|
|
|
DETAIL: Failing row contains (5, check failed, -5).
|
2000-01-05 18:32:18 +01:00
|
|
|
INSERT INTO INSERT_TBL VALUES (7, '!check failed', -7);
|
|
|
|
INSERT INTO INSERT_TBL(y) VALUES ('-!NULL-');
|
2020-12-15 21:54:06 +01:00
|
|
|
SELECT * FROM INSERT_TBL;
|
|
|
|
x | y | z
|
|
|
|
---+---------------+----
|
|
|
|
3 | Y | -3
|
|
|
|
7 | -NULL- | -7
|
|
|
|
7 | !check failed | -7
|
|
|
|
4 | -!NULL- | -4
|
1997-08-28 06:49:34 +02:00
|
|
|
(4 rows)
|
|
|
|
|
2000-01-05 18:32:18 +01:00
|
|
|
INSERT INTO INSERT_TBL(y,z) VALUES ('check failed', 4);
|
2004-06-10 19:56:03 +02:00
|
|
|
ERROR: new row for relation "insert_tbl" violates check constraint "insert_tbl_check"
|
2011-11-29 21:02:10 +01:00
|
|
|
DETAIL: Failing row contains (5, check failed, 4).
|
2000-01-05 18:32:18 +01:00
|
|
|
INSERT INTO INSERT_TBL(x,y) VALUES (5, 'check failed');
|
Apply table and domain CHECK constraints in name order.
Previously, CHECK constraints of the same scope were checked in whatever
order they happened to be read from pg_constraint. (Usually, but not
reliably, this would be creation order for domain constraints and reverse
creation order for table constraints, because of differing implementation
details.) Nondeterministic results of this sort are problematic at least
for testing purposes, and in discussion it was agreed to be a violation of
the principle of least astonishment. Therefore, borrow the principle
already established for triggers, and apply such checks in name order
(using strcmp() sort rules). This lets users control the check order
if they have a mind to.
Domain CHECK constraints still follow the rule of checking lower nested
domains' constraints first; the name sort only applies to multiple
constraints attached to the same domain.
In passing, I failed to resist the temptation to wordsmith a bit in
create_domain.sgml.
Apply to HEAD only, since this could result in a behavioral change in
existing applications, and the potential regression test failures have
not actually been observed in our buildfarm.
2015-03-23 21:59:29 +01:00
|
|
|
ERROR: new row for relation "insert_tbl" violates check constraint "insert_tbl_con"
|
2011-11-29 21:02:10 +01:00
|
|
|
DETAIL: Failing row contains (5, check failed, -5).
|
2000-01-05 18:32:18 +01:00
|
|
|
INSERT INTO INSERT_TBL(x,y) VALUES (5, '!check failed');
|
|
|
|
INSERT INTO INSERT_TBL(y) VALUES ('-!NULL-');
|
2020-12-15 21:54:06 +01:00
|
|
|
SELECT * FROM INSERT_TBL;
|
|
|
|
x | y | z
|
|
|
|
---+---------------+----
|
|
|
|
3 | Y | -3
|
|
|
|
7 | -NULL- | -7
|
|
|
|
7 | !check failed | -7
|
|
|
|
4 | -!NULL- | -4
|
|
|
|
5 | !check failed | -5
|
|
|
|
6 | -!NULL- | -6
|
1997-10-17 11:59:09 +02:00
|
|
|
(6 rows)
|
1997-08-28 06:49:34 +02:00
|
|
|
|
2000-01-05 18:32:18 +01:00
|
|
|
SELECT 'seven' AS one, nextval('insert_seq');
|
|
|
|
one | nextval
|
|
|
|
-------+---------
|
|
|
|
seven | 7
|
1997-10-17 11:59:09 +02:00
|
|
|
(1 row)
|
|
|
|
|
2000-01-05 18:32:18 +01:00
|
|
|
INSERT INTO INSERT_TBL(y) VALUES ('Y');
|
Apply table and domain CHECK constraints in name order.
Previously, CHECK constraints of the same scope were checked in whatever
order they happened to be read from pg_constraint. (Usually, but not
reliably, this would be creation order for domain constraints and reverse
creation order for table constraints, because of differing implementation
details.) Nondeterministic results of this sort are problematic at least
for testing purposes, and in discussion it was agreed to be a violation of
the principle of least astonishment. Therefore, borrow the principle
already established for triggers, and apply such checks in name order
(using strcmp() sort rules). This lets users control the check order
if they have a mind to.
Domain CHECK constraints still follow the rule of checking lower nested
domains' constraints first; the name sort only applies to multiple
constraints attached to the same domain.
In passing, I failed to resist the temptation to wordsmith a bit in
create_domain.sgml.
Apply to HEAD only, since this could result in a behavioral change in
existing applications, and the potential regression test failures have
not actually been observed in our buildfarm.
2015-03-23 21:59:29 +01:00
|
|
|
ERROR: new row for relation "insert_tbl" violates check constraint "insert_tbl_con"
|
2011-11-29 21:02:10 +01:00
|
|
|
DETAIL: Failing row contains (8, Y, -8).
|
2000-01-05 18:32:18 +01:00
|
|
|
SELECT 'eight' AS one, currval('insert_seq');
|
|
|
|
one | currval
|
|
|
|
-------+---------
|
|
|
|
eight | 8
|
1997-08-28 06:49:34 +02:00
|
|
|
(1 row)
|
|
|
|
|
2013-04-20 17:04:41 +02:00
|
|
|
-- According to SQL, it is OK to insert a record that gives rise to NULL
|
2000-01-20 00:55:03 +01:00
|
|
|
-- constraint-condition results. Postgres used to reject this, but it
|
|
|
|
-- was wrong:
|
|
|
|
INSERT INTO INSERT_TBL VALUES (null, null, null);
|
2020-12-15 21:54:06 +01:00
|
|
|
SELECT * FROM INSERT_TBL;
|
|
|
|
x | y | z
|
|
|
|
---+---------------+----
|
|
|
|
3 | Y | -3
|
|
|
|
7 | -NULL- | -7
|
|
|
|
7 | !check failed | -7
|
|
|
|
4 | -!NULL- | -4
|
|
|
|
5 | !check failed | -5
|
|
|
|
6 | -!NULL- | -6
|
|
|
|
| |
|
2000-01-20 00:55:03 +01:00
|
|
|
(7 rows)
|
|
|
|
|
Don't allow system columns in CHECK constraints, except tableoid.
Previously, arbitray system columns could be mentioned in table
constraints, but they were not correctly checked at runtime, because
the values weren't actually set correctly in the tuple. Since it
seems easy enough to initialize the table OID properly, do that,
and continue allowing that column, but disallow the rest unless and
until someone figures out a way to make them work properly.
No back-patch, because this doesn't seem important enough to take the
risk of destabilizing the back branches. In fact, this will pose a
dump-and-reload hazard for those upgrading from previous versions:
constraints that were accepted before but were not correctly enforced
will now either be enforced correctly or not accepted at all. Either
could result in restore failures, but in practice I think very few
users will notice the difference, since the use case is pretty
marginal anyway and few users will be relying on features that have
not historically worked.
Amit Kapila, reviewed by Rushabh Lathia, with doc changes by me.
2013-09-23 19:31:22 +02:00
|
|
|
--
|
|
|
|
-- Check constraints on system columns
|
|
|
|
--
|
|
|
|
CREATE TABLE SYS_COL_CHECK_TBL (city text, state text, is_capital bool,
|
|
|
|
altitude int,
|
|
|
|
CHECK (NOT (is_capital AND tableoid::regclass::text = 'sys_col_check_tbl')));
|
|
|
|
INSERT INTO SYS_COL_CHECK_TBL VALUES ('Seattle', 'Washington', false, 100);
|
|
|
|
INSERT INTO SYS_COL_CHECK_TBL VALUES ('Olympia', 'Washington', true, 100);
|
|
|
|
ERROR: new row for relation "sys_col_check_tbl" violates check constraint "sys_col_check_tbl_check"
|
|
|
|
DETAIL: Failing row contains (Olympia, Washington, t, 100).
|
|
|
|
SELECT *, tableoid::regclass::text FROM SYS_COL_CHECK_TBL;
|
|
|
|
city | state | is_capital | altitude | tableoid
|
|
|
|
---------+------------+------------+----------+-------------------
|
|
|
|
Seattle | Washington | f | 100 | sys_col_check_tbl
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
DROP TABLE SYS_COL_CHECK_TBL;
|
|
|
|
--
|
|
|
|
-- Check constraints on system columns other then TableOid should return error
|
|
|
|
--
|
|
|
|
CREATE TABLE SYS_COL_CHECK_TBL (city text, state text, is_capital bool,
|
|
|
|
altitude int,
|
|
|
|
CHECK (NOT (is_capital AND ctid::text = 'sys_col_check_tbl')));
|
|
|
|
ERROR: system column "ctid" reference in check constraint is invalid
|
2018-08-22 08:42:49 +02:00
|
|
|
LINE 3: CHECK (NOT (is_capital AND ctid::text = 'sys_col_check...
|
|
|
|
^
|
2000-01-16 20:57:48 +01:00
|
|
|
--
|
|
|
|
-- Check inheritance of defaults and constraints
|
|
|
|
--
|
|
|
|
CREATE TABLE INSERT_CHILD (cx INT default 42,
|
|
|
|
cy INT CHECK (cy > x))
|
|
|
|
INHERITS (INSERT_TBL);
|
|
|
|
INSERT INTO INSERT_CHILD(x,z,cy) VALUES (7,-7,11);
|
|
|
|
INSERT INTO INSERT_CHILD(x,z,cy) VALUES (7,-7,6);
|
2004-06-10 19:56:03 +02:00
|
|
|
ERROR: new row for relation "insert_child" violates check constraint "insert_child_check"
|
2011-11-29 21:02:10 +01:00
|
|
|
DETAIL: Failing row contains (7, -NULL-, -7, 42, 6).
|
2000-01-16 20:57:48 +01:00
|
|
|
INSERT INTO INSERT_CHILD(x,z,cy) VALUES (6,-7,7);
|
2004-06-10 19:56:03 +02:00
|
|
|
ERROR: new row for relation "insert_child" violates check constraint "insert_tbl_check"
|
2011-11-29 21:02:10 +01:00
|
|
|
DETAIL: Failing row contains (6, -NULL-, -7, 42, 7).
|
2000-01-16 20:57:48 +01:00
|
|
|
INSERT INTO INSERT_CHILD(x,y,z,cy) VALUES (6,'check failed',-6,7);
|
Apply table and domain CHECK constraints in name order.
Previously, CHECK constraints of the same scope were checked in whatever
order they happened to be read from pg_constraint. (Usually, but not
reliably, this would be creation order for domain constraints and reverse
creation order for table constraints, because of differing implementation
details.) Nondeterministic results of this sort are problematic at least
for testing purposes, and in discussion it was agreed to be a violation of
the principle of least astonishment. Therefore, borrow the principle
already established for triggers, and apply such checks in name order
(using strcmp() sort rules). This lets users control the check order
if they have a mind to.
Domain CHECK constraints still follow the rule of checking lower nested
domains' constraints first; the name sort only applies to multiple
constraints attached to the same domain.
In passing, I failed to resist the temptation to wordsmith a bit in
create_domain.sgml.
Apply to HEAD only, since this could result in a behavioral change in
existing applications, and the potential regression test failures have
not actually been observed in our buildfarm.
2015-03-23 21:59:29 +01:00
|
|
|
ERROR: new row for relation "insert_child" violates check constraint "insert_tbl_con"
|
2011-11-29 21:02:10 +01:00
|
|
|
DETAIL: Failing row contains (6, check failed, -6, 42, 7).
|
2000-01-16 20:57:48 +01:00
|
|
|
SELECT * FROM INSERT_CHILD;
|
|
|
|
x | y | z | cx | cy
|
|
|
|
---+--------+----+----+----
|
|
|
|
7 | -NULL- | -7 | 42 | 11
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
DROP TABLE INSERT_CHILD;
|
2000-01-05 18:32:18 +01:00
|
|
|
--
|
2012-04-21 04:46:20 +02:00
|
|
|
-- Check NO INHERIT type of constraints and inheritance
|
|
|
|
--
|
|
|
|
CREATE TABLE ATACC1 (TEST INT
|
2012-07-24 21:49:54 +02:00
|
|
|
CHECK (TEST > 0) NO INHERIT);
|
2012-04-21 04:46:20 +02:00
|
|
|
CREATE TABLE ATACC2 (TEST2 INT) INHERITS (ATACC1);
|
|
|
|
-- check constraint is not there on child
|
|
|
|
INSERT INTO ATACC2 (TEST) VALUES (-3);
|
|
|
|
-- check constraint is there on parent
|
|
|
|
INSERT INTO ATACC1 (TEST) VALUES (-3);
|
|
|
|
ERROR: new row for relation "atacc1" violates check constraint "atacc1_test_check"
|
|
|
|
DETAIL: Failing row contains (-3).
|
|
|
|
DROP TABLE ATACC1 CASCADE;
|
|
|
|
NOTICE: drop cascades to table atacc2
|
|
|
|
CREATE TABLE ATACC1 (TEST INT, TEST2 INT
|
2012-07-24 21:49:54 +02:00
|
|
|
CHECK (TEST > 0), CHECK (TEST2 > 10) NO INHERIT);
|
2012-04-21 04:46:20 +02:00
|
|
|
CREATE TABLE ATACC2 () INHERITS (ATACC1);
|
|
|
|
-- check constraint is there on child
|
|
|
|
INSERT INTO ATACC2 (TEST) VALUES (-3);
|
|
|
|
ERROR: new row for relation "atacc2" violates check constraint "atacc1_test_check"
|
|
|
|
DETAIL: Failing row contains (-3, null).
|
|
|
|
-- check constraint is there on parent
|
|
|
|
INSERT INTO ATACC1 (TEST) VALUES (-3);
|
|
|
|
ERROR: new row for relation "atacc1" violates check constraint "atacc1_test_check"
|
|
|
|
DETAIL: Failing row contains (-3, null).
|
|
|
|
-- check constraint is not there on child
|
|
|
|
INSERT INTO ATACC2 (TEST2) VALUES (3);
|
|
|
|
-- check constraint is there on parent
|
|
|
|
INSERT INTO ATACC1 (TEST2) VALUES (3);
|
|
|
|
ERROR: new row for relation "atacc1" violates check constraint "atacc1_test2_check"
|
|
|
|
DETAIL: Failing row contains (null, 3).
|
|
|
|
DROP TABLE ATACC1 CASCADE;
|
|
|
|
NOTICE: drop cascades to table atacc2
|
|
|
|
--
|
2000-01-05 18:32:18 +01:00
|
|
|
-- Check constraints on INSERT INTO
|
|
|
|
--
|
|
|
|
DELETE FROM INSERT_TBL;
|
2005-10-03 01:50:16 +02:00
|
|
|
ALTER SEQUENCE INSERT_SEQ RESTART WITH 4;
|
Re-order some regression test scripts for more parallelism.
Move the strings, numerology, insert, insert_conflict, select and
errors tests to be parts of nearby parallel groups, instead of
executing by themselves. (Moving "select" required adjusting the
constraints test, which uses a table named "tmp" as select also
does. There don't seem to be any other conflicts.)
Move psql and stats_ext to the next parallel group, where the rules
test also has a long runtime. To make it safe to run stats_ext in
parallel with rules, I adjusted the latter to only dump views/rules
from the pg_catalog and public schemas, which was what it was doing
anyway. stats_ext makes some views in a transient schema, which now
will not affect rules.
Reorder serial_schedule to match parallel_schedule.
Discussion: https://postgr.es/m/735.1554935715@sss.pgh.pa.us
2019-04-12 00:16:50 +02:00
|
|
|
CREATE TEMP TABLE tmp (xd INT, yd TEXT, zd INT);
|
2000-01-05 18:32:18 +01:00
|
|
|
INSERT INTO tmp VALUES (null, 'Y', null);
|
|
|
|
INSERT INTO tmp VALUES (5, '!check failed', null);
|
|
|
|
INSERT INTO tmp VALUES (null, 'try again', null);
|
|
|
|
INSERT INTO INSERT_TBL(y) select yd from tmp;
|
2020-12-15 21:54:06 +01:00
|
|
|
SELECT * FROM INSERT_TBL;
|
|
|
|
x | y | z
|
|
|
|
---+---------------+----
|
|
|
|
4 | Y | -4
|
|
|
|
5 | !check failed | -5
|
|
|
|
6 | try again | -6
|
1997-08-28 06:49:34 +02:00
|
|
|
(3 rows)
|
|
|
|
|
2000-01-05 18:32:18 +01:00
|
|
|
INSERT INTO INSERT_TBL SELECT * FROM tmp WHERE yd = 'try again';
|
|
|
|
INSERT INTO INSERT_TBL(y,z) SELECT yd, -7 FROM tmp WHERE yd = 'try again';
|
|
|
|
INSERT INTO INSERT_TBL(y,z) SELECT yd, -8 FROM tmp WHERE yd = 'try again';
|
Apply table and domain CHECK constraints in name order.
Previously, CHECK constraints of the same scope were checked in whatever
order they happened to be read from pg_constraint. (Usually, but not
reliably, this would be creation order for domain constraints and reverse
creation order for table constraints, because of differing implementation
details.) Nondeterministic results of this sort are problematic at least
for testing purposes, and in discussion it was agreed to be a violation of
the principle of least astonishment. Therefore, borrow the principle
already established for triggers, and apply such checks in name order
(using strcmp() sort rules). This lets users control the check order
if they have a mind to.
Domain CHECK constraints still follow the rule of checking lower nested
domains' constraints first; the name sort only applies to multiple
constraints attached to the same domain.
In passing, I failed to resist the temptation to wordsmith a bit in
create_domain.sgml.
Apply to HEAD only, since this could result in a behavioral change in
existing applications, and the potential regression test failures have
not actually been observed in our buildfarm.
2015-03-23 21:59:29 +01:00
|
|
|
ERROR: new row for relation "insert_tbl" violates check constraint "insert_tbl_con"
|
2011-11-29 21:02:10 +01:00
|
|
|
DETAIL: Failing row contains (8, try again, -8).
|
2020-12-15 21:54:06 +01:00
|
|
|
SELECT * FROM INSERT_TBL;
|
|
|
|
x | y | z
|
|
|
|
---+---------------+----
|
|
|
|
4 | Y | -4
|
|
|
|
5 | !check failed | -5
|
|
|
|
6 | try again | -6
|
|
|
|
| try again |
|
|
|
|
7 | try again | -7
|
2000-01-20 00:55:03 +01:00
|
|
|
(5 rows)
|
1997-09-16 18:17:19 +02:00
|
|
|
|
2000-01-05 18:32:18 +01:00
|
|
|
DROP TABLE tmp;
|
|
|
|
--
|
|
|
|
-- Check constraints on UPDATE
|
|
|
|
--
|
2000-01-20 00:55:03 +01:00
|
|
|
UPDATE INSERT_TBL SET x = NULL WHERE x = 5;
|
2000-01-05 18:32:18 +01:00
|
|
|
UPDATE INSERT_TBL SET x = 6 WHERE x = 6;
|
|
|
|
UPDATE INSERT_TBL SET x = -z, z = -x;
|
|
|
|
UPDATE INSERT_TBL SET x = z, z = x;
|
Apply table and domain CHECK constraints in name order.
Previously, CHECK constraints of the same scope were checked in whatever
order they happened to be read from pg_constraint. (Usually, but not
reliably, this would be creation order for domain constraints and reverse
creation order for table constraints, because of differing implementation
details.) Nondeterministic results of this sort are problematic at least
for testing purposes, and in discussion it was agreed to be a violation of
the principle of least astonishment. Therefore, borrow the principle
already established for triggers, and apply such checks in name order
(using strcmp() sort rules). This lets users control the check order
if they have a mind to.
Domain CHECK constraints still follow the rule of checking lower nested
domains' constraints first; the name sort only applies to multiple
constraints attached to the same domain.
In passing, I failed to resist the temptation to wordsmith a bit in
create_domain.sgml.
Apply to HEAD only, since this could result in a behavioral change in
existing applications, and the potential regression test failures have
not actually been observed in our buildfarm.
2015-03-23 21:59:29 +01:00
|
|
|
ERROR: new row for relation "insert_tbl" violates check constraint "insert_tbl_con"
|
2011-11-29 21:02:10 +01:00
|
|
|
DETAIL: Failing row contains (-4, Y, 4).
|
2000-01-05 18:32:18 +01:00
|
|
|
SELECT * FROM INSERT_TBL;
|
|
|
|
x | y | z
|
|
|
|
---+---------------+----
|
|
|
|
4 | Y | -4
|
2000-01-20 00:55:03 +01:00
|
|
|
| try again |
|
2000-01-05 18:32:18 +01:00
|
|
|
7 | try again | -7
|
2000-01-20 00:55:03 +01:00
|
|
|
5 | !check failed |
|
2000-01-05 18:32:18 +01:00
|
|
|
6 | try again | -6
|
2000-01-20 00:55:03 +01:00
|
|
|
(5 rows)
|
1997-09-16 18:17:19 +02:00
|
|
|
|
2000-01-05 18:32:18 +01:00
|
|
|
-- DROP TABLE INSERT_TBL;
|
|
|
|
--
|
|
|
|
-- Check constraints on COPY FROM
|
|
|
|
--
|
|
|
|
CREATE TABLE COPY_TBL (x INT, y TEXT, z INT,
|
1997-12-05 01:01:22 +01:00
|
|
|
CONSTRAINT COPY_CON
|
|
|
|
CHECK (x > 3 AND y <> 'check failed' AND x < 7 ));
|
2021-12-20 20:06:15 +01:00
|
|
|
\set filename :abs_srcdir '/data/constro.data'
|
|
|
|
COPY COPY_TBL FROM :'filename';
|
2020-12-15 21:54:06 +01:00
|
|
|
SELECT * FROM COPY_TBL;
|
|
|
|
x | y | z
|
|
|
|
---+---------------+---
|
|
|
|
4 | !check failed | 5
|
|
|
|
6 | OK | 4
|
1997-10-17 11:59:09 +02:00
|
|
|
(2 rows)
|
1997-08-28 06:49:34 +02:00
|
|
|
|
2021-12-20 20:06:15 +01:00
|
|
|
\set filename :abs_srcdir '/data/constrf.data'
|
|
|
|
COPY COPY_TBL FROM :'filename';
|
2003-09-25 17:48:17 +02:00
|
|
|
ERROR: new row for relation "copy_tbl" violates check constraint "copy_con"
|
2011-11-29 21:02:10 +01:00
|
|
|
DETAIL: Failing row contains (7, check failed, 6).
|
2003-09-30 00:06:40 +02:00
|
|
|
CONTEXT: COPY copy_tbl, line 2: "7 check failed 6"
|
2000-01-05 18:32:18 +01:00
|
|
|
SELECT * FROM COPY_TBL;
|
|
|
|
x | y | z
|
|
|
|
---+---------------+---
|
|
|
|
4 | !check failed | 5
|
|
|
|
6 | OK | 4
|
1997-10-17 11:59:09 +02:00
|
|
|
(2 rows)
|
1997-08-28 06:49:34 +02:00
|
|
|
|
2000-01-05 18:32:18 +01:00
|
|
|
--
|
|
|
|
-- Primary keys
|
|
|
|
--
|
|
|
|
CREATE TABLE PRIMARY_TBL (i int PRIMARY KEY, t text);
|
|
|
|
INSERT INTO PRIMARY_TBL VALUES (1, 'one');
|
|
|
|
INSERT INTO PRIMARY_TBL VALUES (2, 'two');
|
|
|
|
INSERT INTO PRIMARY_TBL VALUES (1, 'three');
|
2007-06-04 00:16:03 +02:00
|
|
|
ERROR: duplicate key value violates unique constraint "primary_tbl_pkey"
|
2009-08-01 21:59:41 +02:00
|
|
|
DETAIL: Key (i)=(1) already exists.
|
2000-01-05 18:32:18 +01:00
|
|
|
INSERT INTO PRIMARY_TBL VALUES (4, 'three');
|
|
|
|
INSERT INTO PRIMARY_TBL VALUES (5, 'one');
|
|
|
|
INSERT INTO PRIMARY_TBL (t) VALUES ('six');
|
2020-01-28 03:18:10 +01:00
|
|
|
ERROR: null value in column "i" of relation "primary_tbl" violates not-null constraint
|
2011-11-30 00:29:18 +01:00
|
|
|
DETAIL: Failing row contains (null, six).
|
2020-12-15 21:54:06 +01:00
|
|
|
SELECT * FROM PRIMARY_TBL;
|
|
|
|
i | t
|
|
|
|
---+-------
|
|
|
|
1 | one
|
|
|
|
2 | two
|
|
|
|
4 | three
|
|
|
|
5 | one
|
1997-12-05 01:01:22 +01:00
|
|
|
(4 rows)
|
|
|
|
|
2000-01-05 18:32:18 +01:00
|
|
|
DROP TABLE PRIMARY_TBL;
|
|
|
|
CREATE TABLE PRIMARY_TBL (i int, t text,
|
|
|
|
PRIMARY KEY(i,t));
|
|
|
|
INSERT INTO PRIMARY_TBL VALUES (1, 'one');
|
|
|
|
INSERT INTO PRIMARY_TBL VALUES (2, 'two');
|
|
|
|
INSERT INTO PRIMARY_TBL VALUES (1, 'three');
|
|
|
|
INSERT INTO PRIMARY_TBL VALUES (4, 'three');
|
|
|
|
INSERT INTO PRIMARY_TBL VALUES (5, 'one');
|
|
|
|
INSERT INTO PRIMARY_TBL (t) VALUES ('six');
|
2020-01-28 03:18:10 +01:00
|
|
|
ERROR: null value in column "i" of relation "primary_tbl" violates not-null constraint
|
2011-11-30 00:29:18 +01:00
|
|
|
DETAIL: Failing row contains (null, six).
|
2020-12-15 21:54:06 +01:00
|
|
|
SELECT * FROM PRIMARY_TBL;
|
|
|
|
i | t
|
|
|
|
---+-------
|
|
|
|
1 | one
|
|
|
|
2 | two
|
|
|
|
1 | three
|
|
|
|
4 | three
|
|
|
|
5 | one
|
1997-12-05 01:01:22 +01:00
|
|
|
(5 rows)
|
|
|
|
|
2000-01-05 18:32:18 +01:00
|
|
|
DROP TABLE PRIMARY_TBL;
|
|
|
|
--
|
|
|
|
-- Unique keys
|
|
|
|
--
|
|
|
|
CREATE TABLE UNIQUE_TBL (i int UNIQUE, t text);
|
|
|
|
INSERT INTO UNIQUE_TBL VALUES (1, 'one');
|
|
|
|
INSERT INTO UNIQUE_TBL VALUES (2, 'two');
|
|
|
|
INSERT INTO UNIQUE_TBL VALUES (1, 'three');
|
2007-06-04 00:16:03 +02:00
|
|
|
ERROR: duplicate key value violates unique constraint "unique_tbl_i_key"
|
2009-08-01 21:59:41 +02:00
|
|
|
DETAIL: Key (i)=(1) already exists.
|
2000-01-05 18:32:18 +01:00
|
|
|
INSERT INTO UNIQUE_TBL VALUES (4, 'four');
|
|
|
|
INSERT INTO UNIQUE_TBL VALUES (5, 'one');
|
|
|
|
INSERT INTO UNIQUE_TBL (t) VALUES ('six');
|
|
|
|
INSERT INTO UNIQUE_TBL (t) VALUES ('seven');
|
Add support for INSERT ... ON CONFLICT DO NOTHING/UPDATE.
The newly added ON CONFLICT clause allows to specify an alternative to
raising a unique or exclusion constraint violation error when inserting.
ON CONFLICT refers to constraints that can either be specified using a
inference clause (by specifying the columns of a unique constraint) or
by naming a unique or exclusion constraint. DO NOTHING avoids the
constraint violation, without touching the pre-existing row. DO UPDATE
SET ... [WHERE ...] updates the pre-existing tuple, and has access to
both the tuple proposed for insertion and the existing tuple; the
optional WHERE clause can be used to prevent an update from being
executed. The UPDATE SET and WHERE clauses have access to the tuple
proposed for insertion using the "magic" EXCLUDED alias, and to the
pre-existing tuple using the table name or its alias.
This feature is often referred to as upsert.
This is implemented using a new infrastructure called "speculative
insertion". It is an optimistic variant of regular insertion that first
does a pre-check for existing tuples and then attempts an insert. If a
violating tuple was inserted concurrently, the speculatively inserted
tuple is deleted and a new attempt is made. If the pre-check finds a
matching tuple the alternative DO NOTHING or DO UPDATE action is taken.
If the insertion succeeds without detecting a conflict, the tuple is
deemed inserted.
To handle the possible ambiguity between the excluded alias and a table
named excluded, and for convenience with long relation names, INSERT
INTO now can alias its target table.
Bumps catversion as stored rules change.
Author: Peter Geoghegan, with significant contributions from Heikki
Linnakangas and Andres Freund. Testing infrastructure by Jeff Janes.
Reviewed-By: Heikki Linnakangas, Andres Freund, Robert Haas, Simon Riggs,
Dean Rasheed, Stephen Frost and many others.
2015-05-08 05:31:36 +02:00
|
|
|
INSERT INTO UNIQUE_TBL VALUES (5, 'five-upsert-insert') ON CONFLICT (i) DO UPDATE SET t = 'five-upsert-update';
|
|
|
|
INSERT INTO UNIQUE_TBL VALUES (6, 'six-upsert-insert') ON CONFLICT (i) DO UPDATE SET t = 'six-upsert-update';
|
|
|
|
-- should fail
|
|
|
|
INSERT INTO UNIQUE_TBL VALUES (1, 'a'), (2, 'b'), (2, 'b') ON CONFLICT (i) DO UPDATE SET t = 'fails';
|
|
|
|
ERROR: ON CONFLICT DO UPDATE command cannot affect row a second time
|
|
|
|
HINT: Ensure that no rows proposed for insertion within the same command have duplicate constrained values.
|
2020-12-15 21:54:06 +01:00
|
|
|
SELECT * FROM UNIQUE_TBL;
|
|
|
|
i | t
|
|
|
|
---+--------------------
|
|
|
|
1 | one
|
|
|
|
2 | two
|
|
|
|
4 | four
|
|
|
|
| six
|
|
|
|
| seven
|
|
|
|
5 | five-upsert-update
|
|
|
|
6 | six-upsert-insert
|
Add support for INSERT ... ON CONFLICT DO NOTHING/UPDATE.
The newly added ON CONFLICT clause allows to specify an alternative to
raising a unique or exclusion constraint violation error when inserting.
ON CONFLICT refers to constraints that can either be specified using a
inference clause (by specifying the columns of a unique constraint) or
by naming a unique or exclusion constraint. DO NOTHING avoids the
constraint violation, without touching the pre-existing row. DO UPDATE
SET ... [WHERE ...] updates the pre-existing tuple, and has access to
both the tuple proposed for insertion and the existing tuple; the
optional WHERE clause can be used to prevent an update from being
executed. The UPDATE SET and WHERE clauses have access to the tuple
proposed for insertion using the "magic" EXCLUDED alias, and to the
pre-existing tuple using the table name or its alias.
This feature is often referred to as upsert.
This is implemented using a new infrastructure called "speculative
insertion". It is an optimistic variant of regular insertion that first
does a pre-check for existing tuples and then attempts an insert. If a
violating tuple was inserted concurrently, the speculatively inserted
tuple is deleted and a new attempt is made. If the pre-check finds a
matching tuple the alternative DO NOTHING or DO UPDATE action is taken.
If the insertion succeeds without detecting a conflict, the tuple is
deemed inserted.
To handle the possible ambiguity between the excluded alias and a table
named excluded, and for convenience with long relation names, INSERT
INTO now can alias its target table.
Bumps catversion as stored rules change.
Author: Peter Geoghegan, with significant contributions from Heikki
Linnakangas and Andres Freund. Testing infrastructure by Jeff Janes.
Reviewed-By: Heikki Linnakangas, Andres Freund, Robert Haas, Simon Riggs,
Dean Rasheed, Stephen Frost and many others.
2015-05-08 05:31:36 +02:00
|
|
|
(7 rows)
|
1997-12-05 01:01:22 +01:00
|
|
|
|
2022-02-03 11:29:54 +01:00
|
|
|
DROP TABLE UNIQUE_TBL;
|
|
|
|
CREATE TABLE UNIQUE_TBL (i int UNIQUE NULLS NOT DISTINCT, t text);
|
|
|
|
INSERT INTO UNIQUE_TBL VALUES (1, 'one');
|
|
|
|
INSERT INTO UNIQUE_TBL VALUES (2, 'two');
|
2022-08-04 20:16:26 +02:00
|
|
|
INSERT INTO UNIQUE_TBL VALUES (1, 'three'); -- fail
|
2022-02-03 11:29:54 +01:00
|
|
|
ERROR: duplicate key value violates unique constraint "unique_tbl_i_key"
|
|
|
|
DETAIL: Key (i)=(1) already exists.
|
|
|
|
INSERT INTO UNIQUE_TBL VALUES (4, 'four');
|
|
|
|
INSERT INTO UNIQUE_TBL VALUES (5, 'one');
|
|
|
|
INSERT INTO UNIQUE_TBL (t) VALUES ('six');
|
2022-08-04 20:16:26 +02:00
|
|
|
INSERT INTO UNIQUE_TBL (t) VALUES ('seven'); -- fail
|
2022-02-03 11:29:54 +01:00
|
|
|
ERROR: duplicate key value violates unique constraint "unique_tbl_i_key"
|
|
|
|
DETAIL: Key (i)=(null) already exists.
|
2022-08-04 20:16:26 +02:00
|
|
|
INSERT INTO UNIQUE_TBL (t) VALUES ('eight') ON CONFLICT DO NOTHING; -- no-op
|
2022-02-03 11:29:54 +01:00
|
|
|
SELECT * FROM UNIQUE_TBL;
|
|
|
|
i | t
|
|
|
|
---+------
|
|
|
|
1 | one
|
|
|
|
2 | two
|
|
|
|
4 | four
|
|
|
|
5 | one
|
|
|
|
| six
|
|
|
|
(5 rows)
|
|
|
|
|
2000-01-05 18:32:18 +01:00
|
|
|
DROP TABLE UNIQUE_TBL;
|
|
|
|
CREATE TABLE UNIQUE_TBL (i int, t text,
|
|
|
|
UNIQUE(i,t));
|
|
|
|
INSERT INTO UNIQUE_TBL VALUES (1, 'one');
|
|
|
|
INSERT INTO UNIQUE_TBL VALUES (2, 'two');
|
|
|
|
INSERT INTO UNIQUE_TBL VALUES (1, 'three');
|
|
|
|
INSERT INTO UNIQUE_TBL VALUES (1, 'one');
|
Adjust naming of indexes and their columns per recent discussion.
Index expression columns are now named after the FigureColname result for
their expressions, rather than always being "pg_expression_N". Digits are
appended to this name if needed to make the column name unique within the
index. (That happens for regular columns too, thus fixing the old problem
that CREATE INDEX fooi ON foo (f1, f1) fails. Before exclusion indexes
there was no real reason to do such a thing, but now maybe there is.)
Default names for indexes and associated constraints now include the column
names of all their columns, not only the first one as in previous practice.
(Of course, this will be truncated as needed to fit in NAMEDATALEN. Also,
pkey indexes retain the historical behavior of not naming specific columns
at all.)
An example of the results:
regression=# create table foo (f1 int, f2 text,
regression(# exclude (f1 with =, lower(f2) with =));
NOTICE: CREATE TABLE / EXCLUDE will create implicit index "foo_f1_lower_exclusion" for table "foo"
CREATE TABLE
regression=# \d foo_f1_lower_exclusion
Index "public.foo_f1_lower_exclusion"
Column | Type | Definition
--------+---------+------------
f1 | integer | f1
lower | text | lower(f2)
btree, for table "public.foo"
2009-12-23 03:35:25 +01:00
|
|
|
ERROR: duplicate key value violates unique constraint "unique_tbl_i_t_key"
|
2009-08-01 21:59:41 +02:00
|
|
|
DETAIL: Key (i, t)=(1, one) already exists.
|
2000-01-05 18:32:18 +01:00
|
|
|
INSERT INTO UNIQUE_TBL VALUES (5, 'one');
|
|
|
|
INSERT INTO UNIQUE_TBL (t) VALUES ('six');
|
2020-12-15 21:54:06 +01:00
|
|
|
SELECT * FROM UNIQUE_TBL;
|
|
|
|
i | t
|
|
|
|
---+-------
|
|
|
|
1 | one
|
|
|
|
2 | two
|
|
|
|
1 | three
|
|
|
|
5 | one
|
|
|
|
| six
|
1997-12-05 01:01:22 +01:00
|
|
|
(5 rows)
|
|
|
|
|
2000-01-05 18:32:18 +01:00
|
|
|
DROP TABLE UNIQUE_TBL;
|
2009-07-29 22:56:21 +02:00
|
|
|
--
|
|
|
|
-- Deferrable unique constraints
|
|
|
|
--
|
|
|
|
CREATE TABLE unique_tbl (i int UNIQUE DEFERRABLE, t text);
|
|
|
|
INSERT INTO unique_tbl VALUES (0, 'one');
|
|
|
|
INSERT INTO unique_tbl VALUES (1, 'two');
|
|
|
|
INSERT INTO unique_tbl VALUES (2, 'tree');
|
|
|
|
INSERT INTO unique_tbl VALUES (3, 'four');
|
|
|
|
INSERT INTO unique_tbl VALUES (4, 'five');
|
|
|
|
BEGIN;
|
|
|
|
-- default is immediate so this should fail right away
|
|
|
|
UPDATE unique_tbl SET i = 1 WHERE i = 0;
|
|
|
|
ERROR: duplicate key value violates unique constraint "unique_tbl_i_key"
|
2009-08-01 21:59:41 +02:00
|
|
|
DETAIL: Key (i)=(1) already exists.
|
2009-07-29 22:56:21 +02:00
|
|
|
ROLLBACK;
|
|
|
|
-- check is done at end of statement, so this should succeed
|
|
|
|
UPDATE unique_tbl SET i = i+1;
|
|
|
|
SELECT * FROM unique_tbl;
|
|
|
|
i | t
|
|
|
|
---+------
|
|
|
|
1 | one
|
|
|
|
2 | two
|
|
|
|
3 | tree
|
|
|
|
4 | four
|
|
|
|
5 | five
|
|
|
|
(5 rows)
|
|
|
|
|
|
|
|
-- explicitly defer the constraint
|
|
|
|
BEGIN;
|
|
|
|
SET CONSTRAINTS unique_tbl_i_key DEFERRED;
|
|
|
|
INSERT INTO unique_tbl VALUES (3, 'three');
|
|
|
|
DELETE FROM unique_tbl WHERE t = 'tree'; -- makes constraint valid again
|
|
|
|
COMMIT; -- should succeed
|
|
|
|
SELECT * FROM unique_tbl;
|
|
|
|
i | t
|
|
|
|
---+-------
|
|
|
|
1 | one
|
|
|
|
2 | two
|
|
|
|
4 | four
|
|
|
|
5 | five
|
|
|
|
3 | three
|
|
|
|
(5 rows)
|
|
|
|
|
|
|
|
-- try adding an initially deferred constraint
|
|
|
|
ALTER TABLE unique_tbl DROP CONSTRAINT unique_tbl_i_key;
|
|
|
|
ALTER TABLE unique_tbl ADD CONSTRAINT unique_tbl_i_key
|
|
|
|
UNIQUE (i) DEFERRABLE INITIALLY DEFERRED;
|
|
|
|
BEGIN;
|
|
|
|
INSERT INTO unique_tbl VALUES (1, 'five');
|
|
|
|
INSERT INTO unique_tbl VALUES (5, 'one');
|
|
|
|
UPDATE unique_tbl SET i = 4 WHERE i = 2;
|
|
|
|
UPDATE unique_tbl SET i = 2 WHERE i = 4 AND t = 'four';
|
|
|
|
DELETE FROM unique_tbl WHERE i = 1 AND t = 'one';
|
|
|
|
DELETE FROM unique_tbl WHERE i = 5 AND t = 'five';
|
|
|
|
COMMIT;
|
|
|
|
SELECT * FROM unique_tbl;
|
|
|
|
i | t
|
|
|
|
---+-------
|
|
|
|
3 | three
|
|
|
|
1 | five
|
|
|
|
5 | one
|
|
|
|
4 | two
|
|
|
|
2 | four
|
|
|
|
(5 rows)
|
|
|
|
|
|
|
|
-- should fail at commit-time
|
|
|
|
BEGIN;
|
|
|
|
INSERT INTO unique_tbl VALUES (3, 'Three'); -- should succeed for now
|
|
|
|
COMMIT; -- should fail
|
|
|
|
ERROR: duplicate key value violates unique constraint "unique_tbl_i_key"
|
2009-08-01 21:59:41 +02:00
|
|
|
DETAIL: Key (i)=(3) already exists.
|
2009-07-29 22:56:21 +02:00
|
|
|
-- make constraint check immediate
|
|
|
|
BEGIN;
|
|
|
|
SET CONSTRAINTS ALL IMMEDIATE;
|
|
|
|
INSERT INTO unique_tbl VALUES (3, 'Three'); -- should fail
|
|
|
|
ERROR: duplicate key value violates unique constraint "unique_tbl_i_key"
|
2009-08-01 21:59:41 +02:00
|
|
|
DETAIL: Key (i)=(3) already exists.
|
2009-07-29 22:56:21 +02:00
|
|
|
COMMIT;
|
|
|
|
-- forced check when SET CONSTRAINTS is called
|
|
|
|
BEGIN;
|
|
|
|
SET CONSTRAINTS ALL DEFERRED;
|
|
|
|
INSERT INTO unique_tbl VALUES (3, 'Three'); -- should succeed for now
|
|
|
|
SET CONSTRAINTS ALL IMMEDIATE; -- should fail
|
|
|
|
ERROR: duplicate key value violates unique constraint "unique_tbl_i_key"
|
2009-08-01 21:59:41 +02:00
|
|
|
DETAIL: Key (i)=(3) already exists.
|
2009-07-29 22:56:21 +02:00
|
|
|
COMMIT;
|
2018-03-23 14:48:22 +01:00
|
|
|
-- test deferrable UNIQUE with a partitioned table
|
|
|
|
CREATE TABLE parted_uniq_tbl (i int UNIQUE DEFERRABLE) partition by range (i);
|
|
|
|
CREATE TABLE parted_uniq_tbl_1 PARTITION OF parted_uniq_tbl FOR VALUES FROM (0) TO (10);
|
|
|
|
CREATE TABLE parted_uniq_tbl_2 PARTITION OF parted_uniq_tbl FOR VALUES FROM (20) TO (30);
|
|
|
|
SELECT conname, conrelid::regclass FROM pg_constraint
|
|
|
|
WHERE conname LIKE 'parted_uniq%' ORDER BY conname;
|
|
|
|
conname | conrelid
|
|
|
|
-------------------------+-------------------
|
|
|
|
parted_uniq_tbl_1_i_key | parted_uniq_tbl_1
|
|
|
|
parted_uniq_tbl_2_i_key | parted_uniq_tbl_2
|
|
|
|
parted_uniq_tbl_i_key | parted_uniq_tbl
|
|
|
|
(3 rows)
|
|
|
|
|
|
|
|
BEGIN;
|
|
|
|
INSERT INTO parted_uniq_tbl VALUES (1);
|
|
|
|
SAVEPOINT f;
|
|
|
|
INSERT INTO parted_uniq_tbl VALUES (1); -- unique violation
|
|
|
|
ERROR: duplicate key value violates unique constraint "parted_uniq_tbl_1_i_key"
|
|
|
|
DETAIL: Key (i)=(1) already exists.
|
|
|
|
ROLLBACK TO f;
|
|
|
|
SET CONSTRAINTS parted_uniq_tbl_i_key DEFERRED;
|
|
|
|
INSERT INTO parted_uniq_tbl VALUES (1); -- OK now, fail at commit
|
|
|
|
COMMIT;
|
|
|
|
ERROR: duplicate key value violates unique constraint "parted_uniq_tbl_1_i_key"
|
|
|
|
DETAIL: Key (i)=(1) already exists.
|
|
|
|
DROP TABLE parted_uniq_tbl;
|
2022-09-08 13:17:02 +02:00
|
|
|
-- test naming a constraint in a partition when a conflict exists
|
|
|
|
CREATE TABLE parted_fk_naming (
|
|
|
|
id bigint NOT NULL default 1,
|
|
|
|
id_abc bigint,
|
|
|
|
CONSTRAINT dummy_constr FOREIGN KEY (id_abc)
|
|
|
|
REFERENCES parted_fk_naming (id),
|
|
|
|
PRIMARY KEY (id)
|
|
|
|
)
|
|
|
|
PARTITION BY LIST (id);
|
|
|
|
CREATE TABLE parted_fk_naming_1 (
|
|
|
|
id bigint NOT NULL default 1,
|
|
|
|
id_abc bigint,
|
|
|
|
PRIMARY KEY (id),
|
|
|
|
CONSTRAINT dummy_constr CHECK (true)
|
|
|
|
);
|
|
|
|
ALTER TABLE parted_fk_naming ATTACH PARTITION parted_fk_naming_1 FOR VALUES IN ('1');
|
|
|
|
SELECT conname FROM pg_constraint WHERE conrelid = 'parted_fk_naming_1'::regclass AND contype = 'f';
|
|
|
|
conname
|
|
|
|
--------------------------------
|
|
|
|
parted_fk_naming_1_id_abc_fkey
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
DROP TABLE parted_fk_naming;
|
2009-07-29 22:56:21 +02:00
|
|
|
-- test a HOT update that invalidates the conflicting tuple.
|
|
|
|
-- the trigger should still fire and catch the violation
|
|
|
|
BEGIN;
|
|
|
|
INSERT INTO unique_tbl VALUES (3, 'Three'); -- should succeed for now
|
|
|
|
UPDATE unique_tbl SET t = 'THREE' WHERE i = 3 AND t = 'Three';
|
|
|
|
COMMIT; -- should fail
|
|
|
|
ERROR: duplicate key value violates unique constraint "unique_tbl_i_key"
|
2009-08-01 21:59:41 +02:00
|
|
|
DETAIL: Key (i)=(3) already exists.
|
2009-07-29 22:56:21 +02:00
|
|
|
SELECT * FROM unique_tbl;
|
|
|
|
i | t
|
|
|
|
---+-------
|
|
|
|
3 | three
|
|
|
|
1 | five
|
|
|
|
5 | one
|
|
|
|
4 | two
|
|
|
|
2 | four
|
|
|
|
(5 rows)
|
|
|
|
|
|
|
|
-- test a HOT update that modifies the newly inserted tuple,
|
|
|
|
-- but should succeed because we then remove the other conflicting tuple.
|
|
|
|
BEGIN;
|
|
|
|
INSERT INTO unique_tbl VALUES(3, 'tree'); -- should succeed for now
|
|
|
|
UPDATE unique_tbl SET t = 'threex' WHERE t = 'tree';
|
|
|
|
DELETE FROM unique_tbl WHERE t = 'three';
|
|
|
|
SELECT * FROM unique_tbl;
|
|
|
|
i | t
|
|
|
|
---+--------
|
|
|
|
1 | five
|
|
|
|
5 | one
|
|
|
|
4 | two
|
|
|
|
2 | four
|
|
|
|
3 | threex
|
|
|
|
(5 rows)
|
|
|
|
|
|
|
|
COMMIT;
|
|
|
|
SELECT * FROM unique_tbl;
|
|
|
|
i | t
|
|
|
|
---+--------
|
|
|
|
1 | five
|
|
|
|
5 | one
|
|
|
|
4 | two
|
|
|
|
2 | four
|
|
|
|
3 | threex
|
|
|
|
(5 rows)
|
|
|
|
|
|
|
|
DROP TABLE unique_tbl;
|
2009-12-07 06:22:23 +01:00
|
|
|
--
|
|
|
|
-- EXCLUDE constraints
|
|
|
|
--
|
|
|
|
CREATE TABLE circles (
|
|
|
|
c1 CIRCLE,
|
|
|
|
c2 TEXT,
|
|
|
|
EXCLUDE USING gist
|
2010-01-02 18:53:57 +01:00
|
|
|
(c1 WITH &&, (c2::circle) WITH &&)
|
2009-12-07 06:22:23 +01:00
|
|
|
WHERE (circle_center(c1) <> '(0,0)')
|
|
|
|
);
|
|
|
|
-- these should succeed because they don't match the index predicate
|
|
|
|
INSERT INTO circles VALUES('<(0,0), 5>', '<(0,0), 5>');
|
2010-01-02 18:53:57 +01:00
|
|
|
INSERT INTO circles VALUES('<(0,0), 5>', '<(0,0), 4>');
|
2009-12-07 06:22:23 +01:00
|
|
|
-- succeed
|
|
|
|
INSERT INTO circles VALUES('<(10,10), 10>', '<(0,0), 5>');
|
|
|
|
-- fail, overlaps
|
2010-01-02 18:53:57 +01:00
|
|
|
INSERT INTO circles VALUES('<(20,20), 10>', '<(0,0), 4>');
|
2010-03-22 18:43:28 +01:00
|
|
|
ERROR: conflicting key value violates exclusion constraint "circles_c1_c2_excl"
|
2010-01-02 18:53:57 +01:00
|
|
|
DETAIL: Key (c1, (c2::circle))=(<(20,20),10>, <(0,0),4>) conflicts with existing key (c1, (c2::circle))=(<(10,10),10>, <(0,0),5>).
|
Add support for INSERT ... ON CONFLICT DO NOTHING/UPDATE.
The newly added ON CONFLICT clause allows to specify an alternative to
raising a unique or exclusion constraint violation error when inserting.
ON CONFLICT refers to constraints that can either be specified using a
inference clause (by specifying the columns of a unique constraint) or
by naming a unique or exclusion constraint. DO NOTHING avoids the
constraint violation, without touching the pre-existing row. DO UPDATE
SET ... [WHERE ...] updates the pre-existing tuple, and has access to
both the tuple proposed for insertion and the existing tuple; the
optional WHERE clause can be used to prevent an update from being
executed. The UPDATE SET and WHERE clauses have access to the tuple
proposed for insertion using the "magic" EXCLUDED alias, and to the
pre-existing tuple using the table name or its alias.
This feature is often referred to as upsert.
This is implemented using a new infrastructure called "speculative
insertion". It is an optimistic variant of regular insertion that first
does a pre-check for existing tuples and then attempts an insert. If a
violating tuple was inserted concurrently, the speculatively inserted
tuple is deleted and a new attempt is made. If the pre-check finds a
matching tuple the alternative DO NOTHING or DO UPDATE action is taken.
If the insertion succeeds without detecting a conflict, the tuple is
deemed inserted.
To handle the possible ambiguity between the excluded alias and a table
named excluded, and for convenience with long relation names, INSERT
INTO now can alias its target table.
Bumps catversion as stored rules change.
Author: Peter Geoghegan, with significant contributions from Heikki
Linnakangas and Andres Freund. Testing infrastructure by Jeff Janes.
Reviewed-By: Heikki Linnakangas, Andres Freund, Robert Haas, Simon Riggs,
Dean Rasheed, Stephen Frost and many others.
2015-05-08 05:31:36 +02:00
|
|
|
-- succeed, because violation is ignored
|
|
|
|
INSERT INTO circles VALUES('<(20,20), 10>', '<(0,0), 4>')
|
|
|
|
ON CONFLICT ON CONSTRAINT circles_c1_c2_excl DO NOTHING;
|
|
|
|
-- fail, because DO UPDATE variant requires unique index
|
|
|
|
INSERT INTO circles VALUES('<(20,20), 10>', '<(0,0), 4>')
|
|
|
|
ON CONFLICT ON CONSTRAINT circles_c1_c2_excl DO UPDATE SET c2 = EXCLUDED.c2;
|
|
|
|
ERROR: ON CONFLICT DO UPDATE not supported with exclusion constraints
|
2009-12-07 06:22:23 +01:00
|
|
|
-- succeed because c1 doesn't overlap
|
|
|
|
INSERT INTO circles VALUES('<(20,20), 1>', '<(0,0), 5>');
|
2010-01-02 18:53:57 +01:00
|
|
|
-- succeed because c2 doesn't overlap
|
|
|
|
INSERT INTO circles VALUES('<(20,20), 10>', '<(10,10), 5>');
|
2009-12-07 06:22:23 +01:00
|
|
|
-- should fail on existing data without the WHERE clause
|
|
|
|
ALTER TABLE circles ADD EXCLUDE USING gist
|
2010-01-02 18:53:57 +01:00
|
|
|
(c1 WITH &&, (c2::circle) WITH &&);
|
2010-03-22 18:43:28 +01:00
|
|
|
ERROR: could not create exclusion constraint "circles_c1_c2_excl1"
|
2010-01-02 18:53:57 +01:00
|
|
|
DETAIL: Key (c1, (c2::circle))=(<(0,0),5>, <(0,0),5>) conflicts with key (c1, (c2::circle))=(<(0,0),5>, <(0,0),4>).
|
2011-06-06 04:30:04 +02:00
|
|
|
-- try reindexing an existing constraint
|
|
|
|
REINDEX INDEX circles_c1_c2_excl;
|
2009-12-07 06:22:23 +01:00
|
|
|
DROP TABLE circles;
|
|
|
|
-- Check deferred exclusion constraint
|
|
|
|
CREATE TABLE deferred_excl (
|
|
|
|
f1 int,
|
2015-05-11 18:25:28 +02:00
|
|
|
f2 int,
|
2009-12-07 06:22:23 +01:00
|
|
|
CONSTRAINT deferred_excl_con EXCLUDE (f1 WITH =) INITIALLY DEFERRED
|
|
|
|
);
|
|
|
|
INSERT INTO deferred_excl VALUES(1);
|
|
|
|
INSERT INTO deferred_excl VALUES(2);
|
|
|
|
INSERT INTO deferred_excl VALUES(1); -- fail
|
|
|
|
ERROR: conflicting key value violates exclusion constraint "deferred_excl_con"
|
|
|
|
DETAIL: Key (f1)=(1) conflicts with existing key (f1)=(1).
|
Add support for INSERT ... ON CONFLICT DO NOTHING/UPDATE.
The newly added ON CONFLICT clause allows to specify an alternative to
raising a unique or exclusion constraint violation error when inserting.
ON CONFLICT refers to constraints that can either be specified using a
inference clause (by specifying the columns of a unique constraint) or
by naming a unique or exclusion constraint. DO NOTHING avoids the
constraint violation, without touching the pre-existing row. DO UPDATE
SET ... [WHERE ...] updates the pre-existing tuple, and has access to
both the tuple proposed for insertion and the existing tuple; the
optional WHERE clause can be used to prevent an update from being
executed. The UPDATE SET and WHERE clauses have access to the tuple
proposed for insertion using the "magic" EXCLUDED alias, and to the
pre-existing tuple using the table name or its alias.
This feature is often referred to as upsert.
This is implemented using a new infrastructure called "speculative
insertion". It is an optimistic variant of regular insertion that first
does a pre-check for existing tuples and then attempts an insert. If a
violating tuple was inserted concurrently, the speculatively inserted
tuple is deleted and a new attempt is made. If the pre-check finds a
matching tuple the alternative DO NOTHING or DO UPDATE action is taken.
If the insertion succeeds without detecting a conflict, the tuple is
deemed inserted.
To handle the possible ambiguity between the excluded alias and a table
named excluded, and for convenience with long relation names, INSERT
INTO now can alias its target table.
Bumps catversion as stored rules change.
Author: Peter Geoghegan, with significant contributions from Heikki
Linnakangas and Andres Freund. Testing infrastructure by Jeff Janes.
Reviewed-By: Heikki Linnakangas, Andres Freund, Robert Haas, Simon Riggs,
Dean Rasheed, Stephen Frost and many others.
2015-05-08 05:31:36 +02:00
|
|
|
INSERT INTO deferred_excl VALUES(1) ON CONFLICT ON CONSTRAINT deferred_excl_con DO NOTHING; -- fail
|
2015-10-13 21:33:07 +02:00
|
|
|
ERROR: ON CONFLICT does not support deferrable unique constraints/exclusion constraints as arbiters
|
2009-12-07 06:22:23 +01:00
|
|
|
BEGIN;
|
|
|
|
INSERT INTO deferred_excl VALUES(2); -- no fail here
|
|
|
|
COMMIT; -- should fail here
|
|
|
|
ERROR: conflicting key value violates exclusion constraint "deferred_excl_con"
|
|
|
|
DETAIL: Key (f1)=(2) conflicts with existing key (f1)=(2).
|
|
|
|
BEGIN;
|
|
|
|
INSERT INTO deferred_excl VALUES(3);
|
|
|
|
INSERT INTO deferred_excl VALUES(3); -- no fail here
|
|
|
|
COMMIT; -- should fail here
|
|
|
|
ERROR: conflicting key value violates exclusion constraint "deferred_excl_con"
|
|
|
|
DETAIL: Key (f1)=(3) conflicts with existing key (f1)=(3).
|
2015-05-11 18:25:28 +02:00
|
|
|
-- bug #13148: deferred constraint versus HOT update
|
|
|
|
BEGIN;
|
|
|
|
INSERT INTO deferred_excl VALUES(2, 1); -- no fail here
|
|
|
|
DELETE FROM deferred_excl WHERE f1 = 2 AND f2 IS NULL; -- remove old row
|
|
|
|
UPDATE deferred_excl SET f2 = 2 WHERE f1 = 2;
|
|
|
|
COMMIT; -- should not fail
|
|
|
|
SELECT * FROM deferred_excl;
|
|
|
|
f1 | f2
|
|
|
|
----+----
|
|
|
|
1 |
|
|
|
|
2 | 2
|
|
|
|
(2 rows)
|
|
|
|
|
2009-12-07 06:22:23 +01:00
|
|
|
ALTER TABLE deferred_excl DROP CONSTRAINT deferred_excl_con;
|
|
|
|
-- This should fail, but worth testing because of HOT updates
|
|
|
|
UPDATE deferred_excl SET f1 = 3;
|
|
|
|
ALTER TABLE deferred_excl ADD EXCLUDE (f1 WITH =);
|
2010-03-22 18:43:28 +01:00
|
|
|
ERROR: could not create exclusion constraint "deferred_excl_f1_excl"
|
2009-12-07 06:22:23 +01:00
|
|
|
DETAIL: Key (f1)=(3) conflicts with key (f1)=(3).
|
|
|
|
DROP TABLE deferred_excl;
|
2014-12-23 13:06:44 +01:00
|
|
|
-- Comments
|
2019-06-12 04:30:11 +02:00
|
|
|
-- Setup a low-level role to enforce non-superuser checks.
|
|
|
|
CREATE ROLE regress_constraint_comments;
|
|
|
|
SET SESSION AUTHORIZATION regress_constraint_comments;
|
2014-12-23 13:06:44 +01:00
|
|
|
CREATE TABLE constraint_comments_tbl (a int CONSTRAINT the_constraint CHECK (a > 0));
|
|
|
|
CREATE DOMAIN constraint_comments_dom AS int CONSTRAINT the_constraint CHECK (value > 0);
|
|
|
|
COMMENT ON CONSTRAINT the_constraint ON constraint_comments_tbl IS 'yes, the comment';
|
|
|
|
COMMENT ON CONSTRAINT the_constraint ON DOMAIN constraint_comments_dom IS 'yes, another comment';
|
|
|
|
-- no such constraint
|
|
|
|
COMMENT ON CONSTRAINT no_constraint ON constraint_comments_tbl IS 'yes, the comment';
|
|
|
|
ERROR: constraint "no_constraint" for table "constraint_comments_tbl" does not exist
|
|
|
|
COMMENT ON CONSTRAINT no_constraint ON DOMAIN constraint_comments_dom IS 'yes, another comment';
|
2017-05-30 03:48:26 +02:00
|
|
|
ERROR: constraint "no_constraint" for domain constraint_comments_dom does not exist
|
2014-12-23 13:06:44 +01:00
|
|
|
-- no such table/domain
|
|
|
|
COMMENT ON CONSTRAINT the_constraint ON no_comments_tbl IS 'bad comment';
|
|
|
|
ERROR: relation "no_comments_tbl" does not exist
|
|
|
|
COMMENT ON CONSTRAINT the_constraint ON DOMAIN no_comments_dom IS 'another bad comment';
|
|
|
|
ERROR: type "no_comments_dom" does not exist
|
|
|
|
COMMENT ON CONSTRAINT the_constraint ON constraint_comments_tbl IS NULL;
|
|
|
|
COMMENT ON CONSTRAINT the_constraint ON DOMAIN constraint_comments_dom IS NULL;
|
2019-06-12 04:30:11 +02:00
|
|
|
-- unauthorized user
|
|
|
|
RESET SESSION AUTHORIZATION;
|
|
|
|
CREATE ROLE regress_constraint_comments_noaccess;
|
|
|
|
SET SESSION AUTHORIZATION regress_constraint_comments_noaccess;
|
|
|
|
COMMENT ON CONSTRAINT the_constraint ON constraint_comments_tbl IS 'no, the comment';
|
|
|
|
ERROR: must be owner of relation constraint_comments_tbl
|
|
|
|
COMMENT ON CONSTRAINT the_constraint ON DOMAIN constraint_comments_dom IS 'no, another comment';
|
|
|
|
ERROR: must be owner of type constraint_comments_dom
|
|
|
|
RESET SESSION AUTHORIZATION;
|
2014-12-23 13:06:44 +01:00
|
|
|
DROP TABLE constraint_comments_tbl;
|
|
|
|
DROP DOMAIN constraint_comments_dom;
|
2019-06-12 04:30:11 +02:00
|
|
|
DROP ROLE regress_constraint_comments;
|
|
|
|
DROP ROLE regress_constraint_comments_noaccess;
|