Skip site navigation (1) Skip section navigation (2)

pgsql: Lobotomize typmod check in convert_tuples_by_position,back bran

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: pgsql-committers(at)postgresql(dot)org
Subject: pgsql: Lobotomize typmod check in convert_tuples_by_position,back bran
Date: 2011-05-23 18:43:14
Message-ID: E1QOa5y-00041n-1W@gemulon.postgresql.org (view raw or flat)
Thread:
Lists: 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
------
REL9_0_STABLE

Details
-------
http://git.postgresql.org/pg/commitdiff/e48433e9f81d6aceef2b538f1783fbcc91e1074f

Modified Files
--------------
src/backend/access/common/tupconvert.c |    3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)

pgsql-committers by date

Next:From: Robert HaasDate: 2011-05-23 19:23:08
Subject: pgsql: Improve hash_array() logic for combining hash values.
Previous:From: Peter EisentrautDate: 2011-05-23 18:28:14
Subject: pgsql: Message style improvements

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group