The executor will dump core if it's asked to execute a seqscan on
a relation having no table AM, such as a view. While that shouldn't
really happen, it's possible to get there via catalog corruption,
such as a missing ON SELECT rule. It seems worth installing a defense
against that. There are multiple plausible places for such a defense,
but I picked the planner's get_relation_info().
Per discussion of bug #17646 from Kui Liu. Back-patch to v12 where
the tableam APIs were introduced; in older versions you won't get a
SIGSEGV, so it seems less pressing.
Discussion: https://postgr.es/m/17646-
70c93cfa40365776@postgresql.org
*/
relation = table_open(relationObjectId, NoLock);
+ /*
+ * Relations without a table AM can be used in a query only if they are of
+ * special-cased relkinds. This check prevents us from crashing later if,
+ * for example, a view's ON SELECT rule has gone missing. Note that
+ * table_open() already rejected indexes and composite types.
+ */
+ if (!relation->rd_tableam)
+ {
+ if (!(relation->rd_rel->relkind == RELKIND_FOREIGN_TABLE ||
+ relation->rd_rel->relkind == RELKIND_PARTITIONED_TABLE))
+ ereport(ERROR,
+ (errcode(ERRCODE_WRONG_OBJECT_TYPE),
+ errmsg("cannot open relation \"%s\"",
+ RelationGetRelationName(relation))));
+ }
+
/* Temporary and unlogged relations are inaccessible during recovery. */
if (!RelationNeedsWAL(relation) && RecoveryInProgress())
ereport(ERROR,