forked frompostgres/postgres
- Notifications
You must be signed in to change notification settings - Fork6
Commite48433e
committed
Lobotomize typmod check in convert_tuples_by_position, back branches only.
convert_tuples_by_position was rejecting attempts to coerce a record fieldwith -1 typmod to the same type with a non-default typmod. This is in factthe "correct" thing to do (since we're just going to do a type relabeling,not invoke any length-conversion cast function); but it results inrejecting valid cases like bug #6020, because the source record's tupdescis built from Params that don't have typmod assigned. Since that's aregression from previous versions, which accepted this code, we have to dosomething about it. In HEAD, I've fixed the problem properly by causingthe Params to receive the correct typmods; but the potential for incidentalbehavioral changes seems high enough to make it unattractive to make thesame change in released branches. (And it couldn't be fixed that way in8.4 anyway...) Hence this patch just modifies convert_tuples_by_positionto not complain if either the input or the output tupdesc has typmod -1.This is still a shade tighter checking than we did before 9.0, since beforethat plpgsql failed to consider typmods at all when checking recordcompatibility. (convert_tuples_by_position is currently used only byplpgsql, so we're not affecting other behavior.)Back-patch to 8.4, since we recently back-ported convert_tuples_by_positioninto that branch.1 parent7541d32 commite48433e
1 file changed
+2
-1
lines changedLines changed: 2 additions & 1 deletion
| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
100 | 100 | | |
101 | 101 | | |
102 | 102 | | |
103 | | - | |
| 103 | + | |
| 104 | + | |
104 | 105 | | |
105 | 106 | | |
106 | 107 | | |
| |||
0 commit comments
Comments
(0)