So, then the question is: How burdensome is for the implementor of the schema SPI to achieve this? Should we introduce a wrapper to ensure that if the same question is asked twice, we always get the same answer? (CalciteSchema is such a wrapper.)
The question is: Can the implementor of schema SPI know the boundary between different Statements? If the question is asked twice within the same Statement, the answer should always be the same. And when it comes to the next Statement, it should be able to answer what it is like as of the new Statement time. So in order to allow the implementor to do that, we can either 1) provide a reset callback/mechanism in schema SPI or 2) provide an extra parameter "timestamp" or "query id" each time we call getTable from the schema implementor. Either way it would make the SPI unnecessarily more complicated I think. Doing this in the wrapper, i.e., CalciteSchema is certainly much simpler.
Right now Phoenix/Calcite integration maintains a map in PhoenixSchema (originally not for this purpose), but has to take advantage of the Hooks to clear the map right before a Statement starts, which is definitely not preferred.
There is an existing mechanism for a Schema to indicate whether its contents have changed: Schema.contentsHaveChangedSince(long, long). Is it adequate?
According to javadoc, the Schema.contentsHaveChangedSince(long, long) method is designed for schema caching and the thing we are talking about right now is a different issue and it should work regardless of whether caching is enabled. And even if the application of this method could be extended for this more general purpose, we still need some other mechanism to help it work, and we will be back at the above question again. For example, if "contentsHaveChanged" returns true for our next Statement, we'll have to call a method like "update" on the schema implementor, and this sounds like a combined approach of 1) and 2) mentioned above, coz we have both "reset/update" method and a "timestamp" (from contentsHaveChanged).