setheapoverride() considered harmful

I think we need to get rid of setheapoverride().

As far as I can tell, its purpose is to make tuples created in the
current transaction's current command be considered valid, whereas
ordinarily they'd not be considered valid until the next command starts.
But there is another way to make just-written tuples become valid:
CommandCounterIncrement().  Looking around, I see that some code is
using CommandCounterIncrement() to achieve the same result that other
code is using setheapoverride() for.

The trouble with setheapoverride is that you can turn it off.  For
example, execMain.c uses the following code to start a SELECT INTO:
     intoRelationId = heap_create_with_catalog(intoName,                        tupdesc, RELKIND_RELATION,
parseTree->isTemp);
     setheapoverride(true);
     intoRelationDesc = heap_open(intoRelationId,                                  AccessExclusiveLock);
     setheapoverride(false);

The pg_class tuple inserted by heap_create will not be valid in
the current command, so we have to do *something* to allow heap_open
to see it.  The problem with the above sequence is that once we do
setheapoverride(false), all of a sudden we can't see the tuples inserted
by heap_create anymore.  What happens if we need to see them again
during the current command?

An example where we will actually crash and burn (I believe; haven't
tried to make it happen) is if an SI Reset message arrives later during
the startup of the SELECT INTO, say while we are acquiring read locks
on the source table(s).  relcache.c will try to rebuild all the relcache
entries, and will fail on the intoRelation because it can't see the
pg_class tuple for it.

It seems to me that a much cleaner and safer implementation is
     intoRelationId = heap_create_with_catalog(intoName,                        tupdesc, RELKIND_RELATION,
parseTree->isTemp);
     /* Start a new command so that we see results of heap_create */     CommandCounterIncrement();
     intoRelationDesc = heap_open(intoRelationId,                                  AccessExclusiveLock);

since this way the tuples still look valid if we look at them again
later in the same command.

Comments?  Anyone know a reason not to get rid of setheapoverride?
        regards, tom lane