Re: Materialized view assertion failure in HEAD

I wrote:
> BTW, is there a really solid reason why a matview couldn't be allowed to
> have OIDs on demand, and thereby dodge this whole problem? I'm thinking
> that the analogy to regular views not having OIDs is not a very good
> argument, because certainly matview rows are going to need all the other
> system columns.

Some experimentation says that actually it works just fine to create
matviews with OIDs; the only part of the backend that has a problem with
that is REFRESH MATERIALIZED VIEW, which is easily fixed as per
attached.

If we go in this direction it would probably also be a good idea to
revert the hack in psql/describe.c to prevent it from printing Has OIDs
for matviews.

Also, the fact that Joachim saw this problem in a dump/reload implies
that pg_dump is failing to preserve the state of relhasoids for
matviews, because tvmm hasn't got OIDs in the regression database, but
his stack trace says it did after dump and reload. I haven't looked
into how come, but whichever way we jump as far as the backend behavior,
pg_dump is clearly confused.

Anyway, I think it makes more sense to go in the direction of making
the case work than to introduce messy kluges to prevent matviews from
having OIDs.

Also ... while I was nosing around I noticed this bit in InitPlan():

/*
+ * Unless we are creating a view or are creating a materialized view WITH
+ * NO DATA, ensure that all referenced relations are scannable.
+ */
+ if ((eflags & EXEC_FLAG_WITH_NO_DATA) == 0)
+ ExecCheckRelationsScannable(rangeTable);

ISTM that suppressing this check during a matview refresh is rather
broken, because then it won't complain if the matview reads some other
matview that's in a nonscannable state. Is that really the behavior
we want? (Scanning the rangetable is probably wrong for this anyway
--- it'd be better to put the responsibility into the table-scan-node
initialization functions.)

regards, tom lane