Skip to content

Expand JSON, regex, and advanced expression capabilities - #245

Merged
tse-wei-chen merged 7 commits into
mainfrom
feature/json-regex-expression-capabilities
Sep 2, 2026
Merged

tse-wei-chen merged 7 commits into
mainfrom
feature/json-regex-expression-capabilities

Conversation

@tse-wei-chen

@tse-wei-chen tse-wei-chen commented Sep 2, 2026 •

Copy link
Copy Markdown
Owner

Scope

#245 advances the six-provider capability-expansion phase after #241–#244. The focus is JSON, regex, and provider-native advanced expression spellings while keeping source spelling -> typed semantic -> capability/profile proof -> target lowering -> native spelling.

Completed

Regex source grammar

  • PostgreSQL ~ and !~ parse directly into the closed F# RegexMatch semantic.
  • MySQL REGEXP, RLIKE, NOT REGEXP, and NOT RLIKE normalize to the same semantic.
  • Wrong-dialect spellings fail at the source-dialect boundary.
  • The CLR compatibility seam now carries a dedicated RegexExpr instead of round-tripping through the reserved CORE_REGEX_MATCH function-name string.

Algebraic JSON path

  • Added typed JsonPathSegment = JsonProperty | JsonArrayIndex and private JsonPath.
  • JSON validation and rendering share the same algebraic path parser instead of duplicated path regex interpretation.
  • Constant non-negative array-index extraction is enabled for PostgreSQL/MySQL/SQLite where the existing JSON extraction contract is declared.
  • Array-index mutation remains fail-closed because missing/out-of-range mutation semantics are not proven equivalent across providers.

MySQL JSON arrow

  • MySQL -> is source-version gated at 5.7.9+.
  • The proven source subset requires a JSON column identifier on the left and a literal JSON path on the right.
  • It canonicalizes to the existing JSON extraction semantic.
  • MySQL ->> remains fail-closed because its JSON_UNQUOTE(JSON_EXTRACT(...)) text-result semantic is distinct.

PostgreSQL JSON arrow

  • Added a dedicated closed F# PostgresJsonAccess node rather than lowering PostgreSQL -> into generic CORE_JSON_EXTRACT.
  • Selector shape is typed as property key vs signed 32-bit array index.
  • Result shape is typed as JSON vs text, preserving the semantic difference between -> and ->>.
  • The node survives Parse -> CLR compatibility AST -> F# compiler round-trips structurally through PostgresJsonAccessExpr.
  • Rendering stays native PostgreSQL so json is not silently coerced to jsonb.
  • PostgreSQL JSON arrow is accepted for 9.3+ semantics; an explicitly older source/target profile fails closed.
  • Cross-provider lowering remains fail-closed until JSON/jsonb/text type equivalence is proven.

Validation

  • Grammar bombardment floor: 6,088 total cases.
  • Latest Tests workflow: #1419 — success (11/11 jobs).
  • Latest CodeQL Advanced workflow: #1522 — success.
  • Differential parity job is green.
  • Package smoke is green.
  • No unresolved review threads or review comments.

Safety boundaries retained

  • No arbitrary JSON path text is admitted as executable SQL.
  • Unsupported/dynamic JSON path shapes remain fail-closed.
  • SQLite/Firebird regex remains rejected without an explicit native contract.
  • PostgreSQL JSON arrow is not cross-lowered by guessing result-type equivalence.
  • Provider/version-sensitive source grammar requires the declared capability proof where necessary.
  • Existing main capability coverage remains a floor; this PR only adds supported grammar/capabilities.

@tse-wei-chen
tse-wei-chen marked this pull request as ready for review September 2, 2026 09:53
@tse-wei-chen
tse-wei-chen merged commit bafa4aa into main Sep 2, 2026
15 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant