database/postgres
1
0
Fork 0
mirror of https://github.com/postgres/postgres.git synced 2025-06-27 23:21:58 +03:00
Code Activity

Fix failure for generated column with a not-null domain constraint.

Browse Source 
If a GENERATED column is declared to have a domain data type where
the domain's constraints disallow null values, INSERT commands failed
because we built a targetlist that included coercing a null constant
to the domain's type.  The failure occurred even when the generated
value would have been perfectly OK.  This is adjacent to the issues
fixed in 0da39aa76, but we didn't notice for lack of testing a domain
with such a constraint.

We aren't going to use the result of the targetlist entry for the
generated column --- ExecComputeStoredGenerated will overwrite it.
So it's not really necessary that it have the exact datatype of
the generated column.  This patch fixes the problem by changing
the targetlist entry to be a null Const of the domain's base type,
which should be sufficiently legal.  (We do have to tweak
ExecCheckPlanOutput to accept the situation, though.)

This has been broken since we implemented generated columns.
However, this patch only applies easily as far back as v14, partly
because I (tgl) only carried 0da39aa76 back that far, but mostly
because v14 significantly refactored the handling of INSERT/UPDATE
targetlists.  Given the lack of field complaints and the short
remaining support lifetime of v13, I judge the cost-benefit ratio
not good for devising a version that would work in v13.

Reported-by: jian he <jian.universality@gmail.com>
Author: jian he <jian.universality@gmail.com>
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>
Discussion: https://postgr.es/m/CACJufxG59tip2+9h=rEv-ykOFjt0cbsPVchhi0RTij8bABBA0Q@mail.gmail.com
Backpatch-through: 14
This commit is contained in:
Tom Lane
2025-04-15 12:08:34 -04:00
parent 1b1dc81649
commit 3c39c000c8
4 changed files with 81 additions and 28 deletions
Download Patch File Download Diff File Expand all files Collapse all files

46
src/backend/executor/nodeModifyTable.c
View File

@ -205,19 +205,10 @@ ExecCheckPlanOutput(Relation resultRel, List *targetList)
attr = TupleDescAttr(resultDesc, attno);
attno++;
if (!attr->attisdropped)
{
/* Normal case: demand type match */
if (exprType((Node *) tle->expr) != attr->atttypid)
ereport(ERROR,
(errcode(ERRCODE_DATATYPE_MISMATCH),
errmsg("table row type and query-specified row type do not match"),
errdetail("Table has type %s at ordinal position %d, but query expects %s.",
format_type_be(attr->atttypid),
attno,
format_type_be(exprType((Node *) tle->expr)))));
}
else
/*
* Special cases here should match planner's expand_insert_targetlist.
*/
if (attr->attisdropped)
{
/*
* For a dropped column, we can't check atttypid (it's likely 0).
@ -232,6 +223,35 @@ ExecCheckPlanOutput(Relation resultRel, List *targetList)
errdetail("Query provides a value for a dropped column at ordinal position %d.",
attno)));
}
else if (attr->attgenerated)
{
/*
* For a generated column, the planner will have inserted a null
* of the column's base type (to avoid possibly failing on domain
* not-null constraints). It doesn't seem worth insisting on that
* exact type though, since a null value is type-independent. As
* above, just insist on *some* NULL constant.
*/
if (!IsA(tle->expr, Const) ||
!((Const *) tle->expr)->constisnull)
ereport(ERROR,
(errcode(ERRCODE_DATATYPE_MISMATCH),
errmsg("table row type and query-specified row type do not match"),
errdetail("Query provides a value for a generated column at ordinal position %d.",
attno)));
}
else
{
/* Normal case: demand type match */
if (exprType((Node *) tle->expr) != attr->atttypid)
ereport(ERROR,
(errcode(ERRCODE_DATATYPE_MISMATCH),
errmsg("table row type and query-specified row type do not match"),
errdetail("Table has type %s at ordinal position %d, but query expects %s.",
format_type_be(attr->atttypid),
attno,
format_type_be(exprType((Node *) tle->expr)))));
}
}
if (attno != resultDesc->natts)
ereport(ERROR,