Robert Haas <robertmhaas@gmail.com> writes:
> The existing comments mention that callers must check that the return
> value is not a view, if they care. So if there is currently a single
> coherent definition for what heap_open is supposed to do, it's clearly
> NOT the one Heikki proposes. My guess is that reality is closer to
> your theory of "what got cut-and-pasted".
Well, reality is that in the beginning there was heap_open and
index_open, and nothing else. And there weren't views, so basically
those two functions covered all the interesting types of relations.
We got to the current state of affairs by a series of whatever were the
least invasive code changes at the time; nobody's ever taken a step
back and tried to define what "heap_open" ought to allow from the
standpoint of first principles.
In practice I think it would make sense if heap_open accepts all
relation types on which you can potentially do either a heapscan or
indexscan (offhand those should be the same set of relkinds, I think;
so this is the same in effect as Heikki's proposal, but phrased
differently). So it would have to start rejecting views, and we'd need
to go looking for the consequences of that.
regards, tom lane
