Re: Does slot_deform_tuple need to care about dropped columns?

From: Andres Freund <andres(at)anarazel(dot)de>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Does slot_deform_tuple need to care about dropped columns?
Date: 2018-11-10 01:41:46
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers


On 2018-11-07 12:58:16 -0500, Tom Lane wrote:
> 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.

Done that just now.

> > 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.

Yea, I think it ought to be moot these days. If not we better make it


Andres Freund

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message David Steele 2018-11-10 02:45:18 Re: pgsql: Make WAL segment size configurable at initdb time.
Previous Message Michael Paquier 2018-11-10 00:14:19 Re: Add extension options to control TAP and isolation tests