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 по дате отправления: