Oninit® 4gl2everywhere — SQL Translation Pipeline

SQL coming out of the 4GL client is Informix-flavoured. The bridge's translation pipeline is structured to produce target-dialect SQL in three inspectable stages: a parser produces an abstract syntax tree from Informix SQL; a dialect-independent intermediate representation normalises Informix-specific quirks structurally; and a per-target rewriter emits the target backend's native syntax. Each stage is a separate component, and adding a new target dialect is an additive change to the rewriter rather than a parser modification.

Parser front end

The lexer tokenises Informix SQL keywords, identifiers, literals, and operators. The parser produces an AST node hierarchy — one node type per syntactic category (SELECT, INSERT, UPDATE, DELETE, expression, predicate, identifier). The grammar covers the subset of Informix SQL stock 4GL applications emit; extensions for 4GL-specific constructs are added as new grammar rules.

AST → IR lowering

The AST captures source-shape; the IR captures dialect-independent semantics — column references, types, predicates, projections, aggregates, joins. Lowering normalises Informix-specific quirks (the FIRST n row-limit clause, the MATCHES pattern operator, INTERVAL qualifier specifications, TODAY / MDY() / CURRENT built-ins) into IR shapes that any target dialect can rewrite. New target dialects extend the rewriter without touching the parser.

Dialect rewrite

Each target backend declares a dialect handler that walks the IR and emits SQL text in the target's native syntax. The handler knows about per-target idioms: PostgreSQL's '\xNN'::bytea hex literals, MySQL's STR_TO_DATE, Oracle's TO_DATE, MSSQL's DATEFROMPARTS, the BOOLEAN literal divergence, and the DECIMAL trap (DECIMAL / DECIMAL(p) are floating-point on Informix; only DECIMAL(p,s) is fixed). The rewriter is schema-aware where it needs to be — column types from DESCRIBE drive the disambiguation between BOOLEAN 't' and CHAR 't'.