From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Andres Freund <andres(at)anarazel(dot)de> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Does slot_deform_tuple need to care about dropped columns? |
Date: | 2018-11-07 17:58:16 |
Message-ID: | 20999.1541613496@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Andres Freund <andres(at)anarazel(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2018-11-07 18:03:15 | Re: file cloning in pg_upgrade and CREATE DATABASE |
Previous Message | Andres Freund | 2018-11-07 17:44:03 | Does slot_deform_tuple need to care about dropped columns? |