From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andrew Dunstan <andrew@dunslane.net>
cc: exclusion@gmail.com, pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #17056: Segmentation fault on altering the type of the
 foreign table column with a default
In-reply-to: <4726f847-68fb-a7fc-c5e9-7b9536046fc4@dunslane.net>
References: <17056-4f6f7243d322be6b@postgresql.org>
 <1806408.1623363029@sss.pgh.pa.us>
 <4726f847-68fb-a7fc-c5e9-7b9536046fc4@dunslane.net>
Comments: In-reply-to Andrew Dunstan <andrew@dunslane.net>
	message dated "Thu, 10 Jun 2021 18:55:05 -0400"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <1816294.1623366663.1@sss.pgh.pa.us>
Date: Thu, 10 Jun 2021 19:11:03 -0400
Message-ID: <1816295.1623366663@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/1816295.1623366663%40sss.pgh.pa.us>
Precedence: bulk

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