fix(oracle): NUMBER(p,0) precision-aware mapping (stop silent int narrowing)

[cursor]

Bug

Oracle catalog types like NUMBER(19,0) / NUMBER(38,0) (common bigint-width columns) were always parsed as canonical integer, so cross-dialect migrate/compare emitted Postgres integer / MySQL int / etc. Values above int32 range could truncate or fail on apply — silent narrowing with no warning.

Same-dialect Oracle→Oracle was already safe (translateType no-op).

Fix

In oracle.sql-dialect.ts parseMap for number:

• NUMBER(p,0) with p≤9 → integer
• p≤18 → bigint
• p>18 → decimal(p,0)
• scale>0 / bare NUMBER / NUMBER(p) unchanged (decimal)

Tests

Extended Oracle→Postgres type-mapping cases for p=9/10/18/19/38. Full packages/sql suite green (648).

  

---

Note

Medium Risk
Changes canonical type resolution for common Oracle bigint-width NUMBER columns, affecting emitted DDL on cross-dialect migrate/compare; behavior is intentional and covered by new tests.

Overview
Fixes cross-dialect migrate/compare where Oracle NUMBER(19,0) and NUMBER(38,0) were parsed as canonical integer, so targets like Postgres got integer instead of bigint or numeric(p,0) — silent narrowing past int32 with no warning.

Oracle number parsing in oracle.sql-dialect.ts now uses precision for NUMBER(p,0): p≤9 → integer, p≤18 → bigint, p>18 → decimal. Scale>0, bare NUMBER, and NUMBER(p) without scale=0 stay decimal.

Tests extend Oracle→Postgres expectations for p=9, 10, 18, 19, and 38.

^{Reviewed by Cursor Bugbot for commit ce75656. Bugbot is set up for automated code reviews on this repo. Configure here.}

[cursor]

Bugbot couldn't run - usage limit reached

Bugbot is counted against Cursor usage for this user or team, and this run hit a usage or spend limit.

A user or team admin can review and increase usage limits in the Cursor dashboard.

(requestId: serverGenReqId_73f6ea57-4724-4fe3-b15e-f0e19505f5b9)