Hi, While reviewing some zheap code last week, I noticed that the naming of the ExecStore*Tuple() functions seems a bit unfortunate. One reason is that we are now using slots in all kinds of places other than the executor, so that the "Exec" prefix seems a bit out of place. However, you could argue that this is OK, on the grounds that the functions are defined in the executor. What I noticed, though, is that every new table AM is probably going to need its own type of slot, and it's natural to define those slot support functions in the AM code rather than having every AM shove whatever it's got into execTuples.c.
But if you do that, then you end up with a function with a name like ExecStoreZHeapTuple() which isn't in src/backend/executor, and which furthermore will never be called from the executor, because the executor only knows about a short, hard-coded list of built-in slot types, and ZHeapTuples are not one of them. That function will, rather, only be called from the zheap code. And having a function whose name starts with Exec... that is neither defined in the executor nor used in the executor seems wrong. So I think we should rename these functions before we get too used to the new names. There is a significant advantage in doing that for v12 because people are already going to have to adjust third-party code to compensate for the fact that we no longer have an ExecStoreTuple() function any more. I'm not sure exactly what names would be better. Perhaps just change the "Exec" prefix to "Slot", e.g. SlotStoreHeapTuple(). Or maybe put InSlot at the end, like StoreHeapTupleInSlot(). Or just take those four words - slot, heap, tuple, and store - and put them in any order you like. TupleSlotStoreHeap? -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
