Skip to content

Commit b19255c

Browse files
committed
Throw a more on-point error for functions depending on columns.
ALTER COLUMN TYPE wasn't expecting to find any pg_proc objects depending on the column whose type is to be altered. That indeed wasn't possible when this code was written, but it is possible since we introduced new-style SQL function bodies. It's about as difficult to fix this case as it is to fix dependent views, and we've been punting on those for years, so I don't feel too awful about punting for functions too. (I sure wouldn't risk back-patching such code.) So just throw a more user-facing error. Also, adjust some of the existing comments to reflect that these are all pretty much the same issue. (This patch also fixes it so we will tolerate finding such a dependency during ALTER COLUMN SET EXPRESSION; in that, we need not do anything to the function, so no error is wanted. That problem is new in HEAD.) Per bug #18449 from Alexander Lakhin. Back-patch to v14 where we added new-style SQL functions. Discussion: https://postgr.es/m/18449-f8248467aaa294d5@postgresql.org
1 parent 3752e3d commit b19255c

File tree

1 file changed

+25
-5
lines changed

1 file changed

+25
-5
lines changed

src/backend/commands/tablecmds.c

Lines changed: 25 additions & 5 deletions
Original file line numberDiff line numberDiff line change
@@ -12731,8 +12731,29 @@ ATExecAlterColumnType(AlteredTableInfo *tab, Relation rel,
1273112731
RememberConstraintForRebuilding(foundObject.objectId, tab);
1273212732
break;
1273312733

12734+
case OCLASS_PROC:
12735+
12736+
/*
12737+
* A new-style SQL function can depend on a column, if that
12738+
* column is referenced in the parsed function body. Ideally
12739+
* we'd automatically update the function by deparsing and
12740+
* reparsing it, but that's risky and might well fail anyhow.
12741+
* FIXME someday.
12742+
*/
12743+
ereport(ERROR,
12744+
(errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
12745+
errmsg("cannot alter type of a column used by a function or procedure"),
12746+
errdetail("%s depends on column \"%s\"",
12747+
getObjectDescription(&foundObject, false),
12748+
colName)));
12749+
break;
12750+
1273412751
case OCLASS_REWRITE:
12735-
/* XXX someday see if we can cope with revising views */
12752+
12753+
/*
12754+
* View/rule bodies have pretty much the same issues as
12755+
* function bodies. FIXME someday.
12756+
*/
1273612757
ereport(ERROR,
1273712758
(errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
1273812759
errmsg("cannot alter type of a column used by a view or rule"),
@@ -12748,9 +12769,9 @@ ATExecAlterColumnType(AlteredTableInfo *tab, Relation rel,
1274812769
* specified as an update target, or because the column is
1274912770
* used in the trigger's WHEN condition. The first case would
1275012771
* not require any extra work, but the second case would
12751-
* require updating the WHEN expression, which will take a
12752-
* significant amount of new code. Since we can't easily tell
12753-
* which case applies, we punt for both. FIXME someday.
12772+
* require updating the WHEN expression, which has the same
12773+
* issues as above. Since we can't easily tell which case
12774+
* applies, we punt for both. FIXME someday.
1275412775
*/
1275512776
ereport(ERROR,
1275612777
(errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
@@ -12822,7 +12843,6 @@ ATExecAlterColumnType(AlteredTableInfo *tab, Relation rel,
1282212843
RememberStatisticsForRebuilding(foundObject.objectId, tab);
1282312844
break;
1282412845

12825-
case OCLASS_PROC:
1282612846
case OCLASS_TYPE:
1282712847
case OCLASS_CAST:
1282812848
case OCLASS_COLLATION:

0 commit comments

Comments
 (0)