Shifting backwards already worked -- the offset is added as a Postgres interval, and '-90 days' is a perfectly good one -- but the suggestions only listed forward shifts, so nothing said so. Pulling a plan back a quarter is a normal thing to want. A day-level shift is also the case that most needs the dim_period derivation: 15 Mar 2027 less 90 days is 15 Dec 2026, which crosses from 2027/10 - Mar into 2027/07 - Dec. Copying the period columns across would have labelled it March. The offset is interpolated into the statement, so a typo surfaced as a Postgres parse error from the middle of a CTE. It is parsed on its own first, where the failure is cheap and can name the field. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|---|---|---|
| .. | ||
| auth.js | ||
| log.js | ||
| operations.js | ||
| sources.js | ||
| tables.js | ||
| versions.js | ||