Daniel John Debrunner <[EMAIL PROTECTED]> writes: > [EMAIL PROTECTED] wrote: >> Daniel John Debrunner <[EMAIL PROTECTED]> writes: >>> I think the real bug is that canCacheRow is being passed in as true >>> for the row of (default) when it should be false if the default column >>> definition does not translate to a constant over time. >> >> So the compiler actually generates incorrect parameters for the >> RowResultSet constructor in this case? > > That's my guess.
Good guess :) I've traced it to RowResultSetNode.canWeCacheResults() (no big surprise) which returns false in the CURRENT_TIMESTAMP case, and true in the identity case. canWeCacheResults() use a rather tricky visitor pattern, but I think it ends up returning true because the ResultColumn.expression points to a NumericConstantNode, and NumericConstantNode.getOrderableVariantType() (actually inherited from ConstantNode) returns Qualifier.CONSTANT. CurrentDatetimeOperatorNode.getOrderableVariantType() on the other hand returns Qualifier.QUERY_INVARIANT, which is then transformed to Qualifier.SCAN_INVARIANT in ResultColumn.getOrderableVariantType(). Not sure where the default identity information should be detected in all of this though... -- dt
