postgrespro.git / summary / log / commit / refs

commit    c670d0faace6184216c349a4cf830aa415c58068
Author:   Andres Freund <andres@anarazel.de>
Date:     Sat Nov 10 01:40:40 2018 +0000

    Remove ineffective check against dropped columns from slot_getattr().
    
    Before this commit slot_getattr() checked for dropped
    columns (returning NULL in that case), but only after checking for
    previously deformed columns. As slot_deform_tuple() does not contain
    such a check, the check in slot_getattr() would often not have been
    reached, depending on previous use of the slot.
    
    These days locking and plan invalidation ought to ensure that dropped
    columns are not accessed in query plans. Therefore this commit just
    drops the insufficient check in slot_getattr().  It's possible that
    we'll find some holes againt use of dropped columns, but if so, those
    need to be addressed independent of slot_getattr(), as most accesses
    don't go through that function anyway.
    
    Author: Andres Freund
    Discussion: https://postgr.es/m/20181107174403.zai7fedgcjoqx44p@alap3.anarazel.de


 src/backend/executor/execTuples.c | 11 -----------
 1 file changed, 11 deletions(-)

diff --git a/src/backend/executor/execTuples.c b/src/backend/executor/execTuples.c
index eba52dc928..9f0d9daa82 100644
--- a/src/backend/executor/execTuples.c
+++ b/src/backend/executor/execTuples.c
@@ -1132,17 +1132,6 @@ slot_getattr(TupleTableSlot *slot, int attnum, bool *isnull)
 		return (Datum) 0;
 	}
 
-	/*
-	 * If the attribute's column has been dropped, we force a NULL result.
-	 * This case should not happen in normal use, but it could happen if we
-	 * are executing a plan cached before the column was dropped.
-	 */
-	if (TupleDescAttr(tupleDesc, attnum - 1)->attisdropped)
-	{
-		*isnull = true;
-		return (Datum) 0;
-	}
-
 	/*
 	 * Extract the attribute, along with any preceding attributes.
 	 */


[parent: 1ef6bd2954c4]