pgsql: Lobotomize typmod check in convert_tuples_by_position, back bran
От | Tom Lane |
---|---|
Тема | pgsql: Lobotomize typmod check in convert_tuples_by_position, back bran |
Дата | |
Msg-id | E1QOa5y-00041p-3i@gemulon.postgresql.org обсуждение исходный текст |
Список | pgsql-committers |
Lobotomize typmod check in convert_tuples_by_position, back branches only. convert_tuples_by_position was rejecting attempts to coerce a record field with -1 typmod to the same type with a non-default typmod. This is in fact the "correct" thing to do (since we're just going to do a type relabeling, not invoke any length-conversion cast function); but it results in rejecting valid cases like bug #6020, because the source record's tupdesc is built from Params that don't have typmod assigned. Since that's a regression from previous versions, which accepted this code, we have to do something about it. In HEAD, I've fixed the problem properly by causing the Params to receive the correct typmods; but the potential for incidental behavioral changes seems high enough to make it unattractive to make the same change in released branches. (And it couldn't be fixed that way in 8.4 anyway...) Hence this patch just modifies convert_tuples_by_position to 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 before that plpgsql failed to consider typmods at all when checking record compatibility. (convert_tuples_by_position is currently used only by plpgsql, so we're not affecting other behavior.) Back-patch to 8.4, since we recently back-ported convert_tuples_by_position into that branch. Branch ------ REL8_4_STABLE Details ------- http://git.postgresql.org/pg/commitdiff/c6fc554a825cb2f03ef0a23b7a965da7185ce1be Modified Files -------------- src/backend/access/common/tupconvert.c | 3 ++- 1 files changed, 2 insertions(+), 1 deletions(-)
В списке pgsql-committers по дате отправления: