Re: BUG #17056: Segmentation fault on altering the type of the foreign table column with a default

Andrew Dunstan <andrew@dunslane.net> writes:
> On 6/10/21 6:10 PM, Tom Lane wrote:
>> Hmm.  The equivalent DDL on a plain table works fine, but this is
>> crashing in the code that manipulates attmissingval.  I suspect some
>> confusion about whether a foreign table column should even *have*
>> attmissingval.  Andrew, any thoughts?

> My initial thought would be that it should not. If the foreign table has
> rows with missing columns then it should be up to the foreign server to
> supply them transparently. We have no notion what the foreign semantics
> of missing columns are.

Yeah, that was kind of what I thought.  Probably only RELKIND_RELATION
rels should ever have attmissingval; but certainly, anything without
local storage should not.

> I can take a look at a fix tomorrow. My inclination would be simply to
> skip setting attmissingval for foreign tables.

Seems like in addition to that, we'll need a defense in this specific
code to cope with the case where the foreign column already has an
attmissingval.  Or maybe, the logic to not store a new one will be enough
to keep us from reaching this crash; but we need to be sure it is enough.

            regards, tom lane