diff options
| author | Robert Haas <rhaas@postgresql.org> | 2013-09-23 13:31:22 -0400 |
|---|---|---|
| committer | Robert Haas <rhaas@postgresql.org> | 2013-09-23 13:31:22 -0400 |
| commit | ba3d39c96921c96de114f6c22a9572bff24708b5 (patch) | |
| tree | 394fd3046d1903f16dfdb4152082f7f2bfd336c8 /src/backend/executor/nodeModifyTable.c | |
| parent | ff2a1f5e84ee9984b33ee31e6fb9c6f2760a820e (diff) | |
| download | postgresql-ba3d39c96921c96de114f6c22a9572bff24708b5.tar.gz postgresql-ba3d39c96921c96de114f6c22a9572bff24708b5.zip | |
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.
Diffstat (limited to 'src/backend/executor/nodeModifyTable.c')
| -rw-r--r-- | src/backend/executor/nodeModifyTable.c | 12 |
1 files changed, 12 insertions, 0 deletions
diff --git a/src/backend/executor/nodeModifyTable.c b/src/backend/executor/nodeModifyTable.c index 15f5dccb82a..189df713eab 100644 --- a/src/backend/executor/nodeModifyTable.c +++ b/src/backend/executor/nodeModifyTable.c @@ -247,6 +247,12 @@ ExecInsert(TupleTableSlot *slot, else { /* + * Constraints might reference the tableoid column, so initialize + * t_tableOid before evaluating them. + */ + tuple->t_tableOid = RelationGetRelid(resultRelationDesc); + + /* * Check the constraints of the tuple */ if (resultRelationDesc->rd_att->constr) @@ -654,6 +660,12 @@ ExecUpdate(ItemPointer tupleid, LockTupleMode lockmode; /* + * Constraints might reference the tableoid column, so initialize + * t_tableOid before evaluating them. + */ + tuple->t_tableOid = RelationGetRelid(resultRelationDesc); + + /* * Check the constraints of the tuple * * If we generate a new candidate tuple after EvalPlanQual testing, we |