Skip to content

feat: add numeric_precision/scale and seq_in_fk for DDL type fidelity (#142) - #143

Open
aesslinger wants to merge 1 commit into
mainfrom
feat/142-numeric-precision-fk-seq
Open

aesslinger wants to merge 1 commit into
mainfrom
feat/142-numeric-precision-fk-seq

Conversation

@aesslinger

Copy link
Copy Markdown
Collaborator

Summary

Fixes #142. Adds three new optional fields to the plugin's get_columns and get_foreign_keys responses so Tabularis generates DDL with correct type modifiers (numeric(10,2) instead of bare numeric) and composite foreign key column order. Companion to Tabularis PR #939 ("fix: restore type fidelity in Generate SQL / Create Table (#840)").

All fields are additive (optional, omitted when absent) — safe to ship before or after #939 lands. Verified empirically that the current host (without #939) ignores the extra fields (serde's default: no deny_unknown_fields).

Changes

get_columns / get_view_columns / get_all_columns_batch (3 SQL queries)

  • Added c.numeric_precision and c.numeric_scale to all three information_schema.columns queries
  • row_to_table_column extracts them as Option<i32> and includes them as optional JSON fields (only when present — matching the character_maximum_length pattern)

get_foreign_keys / get_all_foreign_keys_batch (2 SQL queries)

  • Changed unnest(con.conkey, con.confkey) AS cols(src_attnum, ref_attnum) to WITH ORDINALITY AS cols(src_attnum, ref_attnum, key_seq) — the true composite-key column order, independent of raw attnum
  • Added cols.key_seq to the SELECT; changed ORDER BY from cols.src_attnum to cols.key_seq
  • row_to_foreign_key extracts key_seq as Option<i64>, narrows to Option<i32>, and includes seq_in_fk as an optional JSON field

FK field names — already compatible

The plugin already uses name, ref_table, ref_column (the names PR #939's PLUGIN_GUIDE.md documents). No rename needed.

Verification

Check Result
cargo fmt --check + cargo clippy --all-targets -- -D warnings clean
Unit tests 400 passed
Live tests (podman 54320) 3 passed
live_db suite 30 passed
Cross-repo parity suite 83/83 passed (exit code 0)

Manual end-to-end verification

Scenario Result
numeric(10,2) → numeric_precision=10, numeric_scale=2 ✅
numeric(5) → numeric_precision=5, numeric_scale=0 ✅
numeric (no precision) → fields omitted ✅
varchar/text/boolean/timestamptz → fields omitted ✅
Composite FK (y, x) REFERENCES (b, a) → seq_in_fk=1 for y, seq_in_fk=2 for x ✅
Single-column FK → seq_in_fk=1 ✅

Compatibility

  • Before #939 lands: the current host ignores the new fields (serde default: no deny_unknown_fields — verified empirically with a test against the actual TableColumn/ForeignKey structs on TabularisDB/main)
  • After #939 lands: the host picks up the new fields automatically — sqlGenerator.ts uses null-safe checks (column.numeric_precision != null, column.numeric_scale ?? 0, a.seq_in_fk ?? Number.MAX_SAFE_INTEGER)
  • Parity suite: the golden files are updated by #939 (not by this PR); the plugin's parity tests pass against the current golden files

…#142)

Adds three new optional fields to the plugin's get_columns and
get_foreign_keys responses so Tabularis generates DDL with correct type
modifiers and composite FK column order (Tabularis #840, PR #939):

get_columns / get_view_columns / get_all_columns_batch:
- Added c.numeric_precision and c.numeric_scale to all three
  information_schema.columns queries.
- row_to_table_column extracts them as Option<i32> and includes them
  as optional JSON fields (only when present, matching the
  character_maximum_length pattern). Without these, numeric(10,2)
  columns generate as bare numeric in CREATE TABLE DDL.

get_foreign_keys / get_all_foreign_keys_batch:
- Changed unnest(con.conkey, con.confkey) to WITH ORDINALITY to get
  key_seq — the true composite-key column order, independent of raw
  attnum. Changed ORDER BY from cols.src_attnum to cols.key_seq.
- row_to_foreign_key extracts key_seq as Option<i64>, narrows to
  Option<i32>, and includes seq_in_fk as an optional JSON field.
  Without this, composite FK columns may be in the wrong order in
  generated DDL.

All fields are additive (optional, omitted when absent) — the current
host ignores unknown fields and the PR #939 host uses null-safe checks,
so this is safe to ship before or after #939 lands.

Verified: 400 unit tests green, 3 live tests green, 30 live_db tests
green, 83/83 cross-repo parity suite unchanged, clippy + fmt clean.
Manual verification: numeric(10,2) → prec=10 scale=2, composite FK
(y,x) → seq_in_fk=1,2 ordered by constraint definition.
@aesslinger aesslinger added the prerelease:rc Version suggestion targets a release candidate label Oct 9, 2026
@aesslinger aesslinger self-assigned this Oct 9, 2026
@github-actions

github-actions Bot commented Oct 9, 2026

Copy link
Copy Markdown

Version suggestion

Based on this PR's title (feat) and the prerelease:rc label:

Current 1.0.0-rc.7
Suggested next tag v1.0.0-rc.8

This is informational only — no tag or release is created automatically yet.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

prerelease:rc Version suggestion targets a release candidate

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Add numeric_precision/numeric_scale to get_columns and seq_in_fk to get_foreign_keys for DDL type fidelity (#840)

1 participant