Re: Does slot_deform_tuple need to care about dropped columns?
| От | Tom Lane | 
|---|---|
| Тема | Re: Does slot_deform_tuple need to care about dropped columns? | 
| Дата | |
| Msg-id | 20999.1541613496@sss.pgh.pa.us обсуждение исходный текст  | 
		
| Ответ на | Does slot_deform_tuple need to care about dropped columns? (Andres Freund <andres@anarazel.de>) | 
| Ответы | 
                	
            		Re: Does slot_deform_tuple need to care about dropped columns?
            		
            		 | 
		
| Список | pgsql-hackers | 
Andres Freund <andres@anarazel.de> writes:
> ... in the case the attribute isn't already deformed, the
> following hunk exists:
>     /*
>      * 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;
>     }
> Which strikes me as quite odd. If somebody previously accessed a *later*
> column (be it via slot_getattr, or slot_getsomeattrs), the whole
> attisdropped check is neutralized.
Good point.  Let's remove it and see what happens.
> Tom, you added that code way back when, in a9b05bdc8330. And as far as I
> can tell that issue existed back then too.
I was just transposing code that had existed before that in ExecEvalVar.
Evidently I didn't think hard about whether the protection was
bulletproof.  But since it isn't, maybe we don't need it at all.
I think our checks for obsoleted plans are a lot more bulletproof
than they were back then, so it's entirely likely the issue is moot.
            regards, tom lane
		
	В списке pgsql-hackers по дате отправления: