docs: `offset_expr` RANGE rule still cites `timestamp`, removed in v0.88.0

[nielspardon]

The RANGE offset_expr type-compatibility rule gives timestamp/interval_day as its first example, but timestamp was removed from the spec in #994, first released in v0.88.0. The rule text postdates that removal, so the example was stale on arrival. It should read precision_timestamp/interval_day, which makes the example correct: functions_datetime.yaml declares add(precision_timestamp<P>, interval_day<P>) -> precision_timestamp<P>, so add(T, D) -> T holds exactly.

Three places carry it, all identical at v0.103.1:

• proto/substrait/algebra.proto#L1469-L1474 — Preceding.offset_expr
• proto/substrait/algebra.proto#L1506-L1511 — Following.offset_expr
• site/docs/expressions/window_functions.md#L34 — the prose rule

The proto comment, quoted from the first of those:

// * BOUNDS_TYPE_RANGE: evaluates to a non-negative distance
//   applied toward values earlier in the declared ordering in `sorts`.
//   Its type D must be compatible with the type T of the single ordering
//   expression, i.e. `add(T, D) -> T` and `subtract(T, D) -> T` must
//   be defined (e.g. timestamp/interval_day, decimal/decimal,
//   i64/i64).

These are the only remaining bare-timestamp type references under proto/ and site/docs/ — the other matches are the English word, not the type.

Filed separately from the substantive question about whether add(T, D) -> T is meant literally, since this part is just a stale name.

🤖 Generated with AI