feat(plan): persist and reflect TTL table options (#24552)#24779
Draft
ck89119 wants to merge 5 commits into
Draft
feat(plan): persist and reflect TTL table options (#24552)#24779ck89119 wants to merge 5 commits into
ck89119 wants to merge 5 commits into
Conversation
First step of native table-level TTL (auto-expiry), parser layer only,
syntax aligned with TiDB:
CREATE TABLE t (id INT, ts TIMESTAMP)
TTL = `ts` + INTERVAL 7 DAY
TTL_ENABLE = 'ON'
TTL_JOB_INTERVAL = '1h';
ALTER TABLE t TTL = `ts` + INTERVAL 30 DAY;
ALTER TABLE t REMOVE TTL;
Changes:
- New non-reserved keywords TTL / TTL_ENABLE / TTL_JOB_INTERVAL
- table_option branches for the three options; the TTL expression is
stored as a `col + INTERVAL n unit` binary expression
- alter_option `REMOVE TTL` (table_option already flows into
alter_option, so set/modify works for ALTER without extra nodes)
- tree nodes TableOptionTTL / TableOptionTTLEnable /
TableOptionTTLJobInterval and AlterTableRemoveTTL
- unit tests: dialect roundtrip + AST assertions + tree Format/Free
The plan layer still rejects these options as not-supported; persistence
to TableDef and the background expiry job land in later PRs.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
…igin#24552) Address review feedback on PR matrixorigin#24754: - TableOptionTTLEnable / TableOptionTTLJobInterval Format now escape embedded single quotes (' -> '') so the output re-parses - tree test now exercises the real `col + INTERVAL n unit` output path and the quote-escaping path (instead of a plain numeric literal) - dialect test now covers ALTER TABLE TTL options written without `=` Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
PR-2 of native table-level TTL, building on the parser layer (PR-1). - buildCreateTable: validate and persist TTL / TTL_ENABLE / TTL_JOB_INTERVAL as table properties (rel_ttl / rel_ttl_enable / rel_ttl_job_interval), applying defaults (enable=on, job_interval=1h) and rejecting invalid combinations (non-time column, bad interval, a sub-option without TTL, temporary/cluster/dynamic/external tables) - SHOW CREATE TABLE: reflect the TTL clause, round-trippable through the parser - ttl_util.go: TTL expression / option validation helpers - tests: validation, persistence with defaults, error cases, SHOW round-trip ALTER TABLE TTL persistence and the background expiry job land in later PRs. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Qodo reviews are paused for this user.Troubleshooting steps vary by plan Learn more → On a Teams plan? Using GitHub Enterprise Server, GitLab Self-Managed, or Bitbucket Data Center? |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What type of PR is this?
Which issue(s) this PR fixes:
issue #24552
What this PR does / why we need it:
Second step of native table-level TTL: persist the TTL table options into the
table metadata on
CREATE TABLE, and reflect them back inSHOW CREATE TABLE.Changes
buildCreateTable(build_ddl.go): validate and persistTTL/TTL_ENABLE/TTL_JOB_INTERVALas table properties(
rel_ttl/rel_ttl_enable/rel_ttl_job_interval), reusing the sameproperty mechanism as
COMMENT. Defaults are applied (enable=on,job_interval=1h). Invalid usage is rejected:DATE/DATETIME/TIMESTAMPTTL_JOB_INTERVALmust be a positive duration (e.g.1h,30m)TTL_ENABLEmust beon/offTTL_ENABLE/TTL_JOB_INTERVALwithout aTTLexpression is an errorConstructCreateTableSQL(build_show_util.go): reflect the TTL clause,round-trippable through the parser; the TTL keys are excluded from the
generic
PROPERTIES()clause.ttl_util.go: TTL expression / option validation helpers.pkg/catalog/types.go: newSystemRelAttr_TTL*property-key constants.SHOW CREATE TABLEround-trip.Scope / safety
ALTER TABLE ... TTLis still rejected as not-supported (lands in a later PR),as is the background expiry job. No behavior change for tables without TTL.
make,make static-checkandgo test ./pkg/sql/plan/...all pass.