Dialect-Aware Logical Query Planning

• Dialect-Aware Logical Query Planning is a framework that converts natural-language queries into structured logical plans by separating semantic intent from surface linguistic variations.
• It employs intermediate representations—such as stepwise plans, operator trees, and DAGs—to handle variability across natural language, SQL dialects, and backend execution forms.
• The approach improves schema-linking and operator selection, leveraging explicit planner–executor separation and knowledge grounding to enhance cross-dialect execution accuracy.

Dialect-aware logical query planning is the problem of converting a natural-language query into an explicit logical plan while accounting for variation across language varieties, database dialects, and execution environments. In the literature summarized here, “dialect” refers to at least three distinct axes: natural-language variation in the input, such as Moroccan Darija or bilingual English–Chinese phrasing; SQL dialect variation across engines such as PostgreSQL, MySQL, Oracle, DuckDB, ClickHouse, and Snowflake; and backend-specific execution formalisms that generalize beyond SQL into query plans, DAGs, or operator trees. The unifying idea is to separate semantic intent from surface realization: first recover a logical structure of sourcing, filtering, joining, aggregation, ordering, or multi-hop decomposition, then realize or validate that structure under the constraints of a target dialect or backend (Chafik et al., 20 Jan 2025).

1. Conceptual scope and problem formulation

Dialect-aware logical query planning is framed in several closely related ways. In dialect-specific NL2SQL, the task is: given a natural language question $q$, a database schema $\mathcal{S}$, and a target database dialect $d$, generate a SQL query $s$ such that $s$ is executable under dialect $d$ and correctly realizes the semantic intent of $q$ over $\mathcal{S}$ (Zhang et al., 8 Mar 2026). In planning-centric bilingual NL2SQL, the mapping is decomposed into a planner $f_{\text{plan}}$ from $(Q,\mathcal{D})$ to a stepwise natural-language plan $\mathcal{S}$0, and a SQL agent $\mathcal{S}$1 from $\mathcal{S}$2 to executable SQL $\mathcal{S}$3, so that $\mathcal{S}$4 (Liu et al., 27 Oct 2025). In text-to-query-plan work outside traditional DBMSs, the task is to transform a natural-language query $\mathcal{S}$5 into a logical query plan $\mathcal{S}$6, defined over an operator library $\mathcal{S}$7, and optimize

$\mathcal{S}$8

where $\mathcal{S}$9 is the set of tables and $d$0 is the true answer (Zhang et al., 26 Aug 2025).

A central distinction across the literature is between direct query generation and explicit planning. Direct generation systems map question and schema directly to SQL or another target language. Planning-centric systems instead introduce an intermediate representation: stepwise natural-language plans, operator trees, QPL programs, DAGs over tools, or logical query trees. This separation is motivated by the claim that dialectal and multilingual variability often corrupts schema-linking, operator selection, and condition extraction if all reasoning is forced into a single sequence-generation step (Liu et al., 27 Oct 2025). The same concern appears in cross-dialect SQL evaluation, where performance on SQLite is shown to be an unreliable proxy for other dialects; cross-dialect degradation is attributed predominantly to logical rather than purely syntactic failures (Perlitz et al., 8 May 2026).

The topic also spans both “input dialects” and “output dialects.” On the input side, Moroccan Darija introduces mixed lexicon, borrowed words, orthographic variation, and pragmatic phrasing that must be mapped into filters, joins, and projections (Chafik et al., 20 Jan 2025). On the output side, enterprise systems require dialect-correct SQL, where syntax rules, built-in functions, and implicit constraints vary across engines (Zhang et al., 8 Mar 2026). A plausible implication is that dialect-aware planning is best viewed as a two-sided grounding problem: natural-language variability must be mapped into a stable logical form, and that logical form must then be rendered into an engine-specific realization.

2. Intermediate representations and logical plan structures

The literature converges on a family of intermediate representations that decouple semantic structure from target syntax. One line of work uses a Natural Language Logical Query Plan (NL-LQP), a sequence

$d$1

where the operators denote data sourcing, filtering, scalar calculation, aggregation, result organization, and auxiliary logic (Zhang et al., 8 Mar 2026). Dial then applies a labeling function

$d$2

to isolate dialect-sensitive operators, and further maps each such operator into a functional category $d$3, producing $d$4 (Zhang et al., 8 Mar 2026). This yields a plan that is dialect-neutral in structure but dialect-aware in specification.

A second line represents plans as explicit programs over algebraic operators. Query Plan Language (QPL) is a modular dataflow language in which leaves are Scan nodes and internal nodes are unary or binary operators such as Aggregate, Filter, Join, Union, Intersect, Except, Sort, and TopSort (Eyal et al., 2023). QPL is described as a high-level abstraction of physical execution plans, restricted to a small set of regular, context-free logical operators, and every sub-plan is itself executable. The paper translates each QPL node deterministically into one SQL CTE, producing a restricted WITH-based SQL program in which each clause corresponds to a plan node (Eyal et al., 2023). This makes plan depth a natural complexity metric: depth $d$5 is a single Scan, while deeper plans correspond to successively composed operators.

A third line generalizes plans beyond SQL into tree or DAG structures. In text-to-query-plan work for large tables, logical plans are tree-structured computational graphs whose leaves are raw tables, internal nodes are intermediate result tables produced by operators, and root nodes are final answers (Zhang et al., 26 Aug 2025). In hybrid data lakes, A.DOT compiles natural-language questions into DAG execution plans $d$6, where each node is an atomic sub-query assigned to exactly one tool and edges encode dependencies through variable references such as "$var_d.column&quot;</code> (<a href="/papers/2603.14229" title="" rel="nofollow" data-turbo="false" class="assistant-link" x-data x-tooltip.raw="">B et al., 15 Mar 2026</a>). In <a href="https://www.emergentmind.com/topics/planrag" title="" rel="nofollow" data-turbo="false" class="assistant-link" x-data x-tooltip.raw="">PlanRAG</a>, exploratory reasoning problems are represented as logical query trees $d$7, where each node is an atomic query and the root is resolved by bottom-up aggregation, rewriting, retrieval, and generation (Xu et al., 1 Jul 2026).

These representations differ in surface form but share two technical properties. First, they externalize composition: joins, filters, and aggregations are no longer implicit in a single SQL string, but are decomposed into named steps or typed nodes. Second, they support localized validation and transformation. QPL supports plan-level complexity analysis and compositional decoding (Eyal et al., 2023). A.DOT validates node fields, dependency references, and acyclicity before execution (B et al., 15 Mar 2026). SQLFlex uses clause-level and expression-level segmentation to parse diverse SQL dialects into ASTs that preserve core logical structure while isolating dialect-specific fragments (An et al., 17 Mar 2026). This suggests that dialect-aware planning increasingly depends on intermediate forms that are simultaneously semantically explicit, locally checkable, and only loosely coupled to any one target language.

3. Dialect phenomena in natural language and database languages

On the natural-language side, Dialect2SQL makes explicit that dialect-aware planning cannot be reduced to simple translation noise. The dataset contains 9,428 NLQ–SQL pairs across 69 databases, derived from the training portion of BIRD, with long schemas, dirty values, and complex SQL, but with questions translated into Moroccan Darija while schemas and SQL remain in English/SQL (Chafik et al., 20 Jan 2025). Darija introduces mixed Arabic, Berber, French, and Spanish lexicon; borrowed stems with Darija morphology; non-standard orthography; and pragmatic phrasing that often expresses constraints indirectly. Concrete planning requirements include cross-lingual entity resolution, foreign-key reasoning, mapping colloquial phrases to Boolean predicates, and recovering implicit comparative or temporal operators (Chafik et al., 20 Jan 2025). The paper reports average translation error scores of CER $d$8, WER $d$9, TER $s$0, and CharacTER $s$1, using

$s$2

which highlights the fragility of any pipeline that relies purely on automatic dialect translation before planning (Chafik et al., 20 Jan 2025).

Multilingual planning in Archer exhibits related but distinct issues. OraPlan-SQL addresses English and Chinese questions with schemas mainly in English, so transliteration and entity mismatch become central. The paper reports that a translation-based Chinese pipeline achieves 55.8% execution accuracy, whereas direct Chinese-to-plan generation reaches 79.8% (Liu et al., 27 Oct 2025). Its remedy is not only bilingual planning, but entity-linking guidelines that require the planner to generate alternative surface forms for every named entity and include them explicitly in the plan. This is planning-level language awareness rather than a post hoc repair heuristic.

On the output side, dialect variation spans syntax, function libraries, and semantic constraints. Dial defines SQL dialects by syntactic rules, function differences, and semantic variations such as NULL sorting, type semantics, and the PostgreSQL rule that under SELECT DISTINCT, all ORDER BY expressions must appear in the select list (Zhang et al., 8 Mar 2026). MoMQ broadens the notion further by covering both relational SQL dialects and graph query dialects: MySQL and PostgreSQL on one side, Cypher and nGQL on the other (Lin et al., 2024). In this setting, “dialect” includes shifts from relational joins to graph pattern matching or traversal primitives, not merely function-name differences. SQLFlex addresses the parsing side of this problem by combining grammar-based parsing with LLM-based segmentation so that a core SQL-92 structure is recovered while dialect-specific fragments are isolated as stable AST substructures (An et al., 17 Mar 2026).

Cross-dialect evaluation shows that these differences matter semantically. PolySQL constructs backend-isomorphic evaluation environments for PostgreSQL, MySQL, BigQuery, Snowflake, and ClickHouse, and reports a 10.1% average accuracy drop from SQLite to other dialects (Perlitz et al., 8 May 2026). It finds low per-query agreement between SQLite and target dialect performance, with average Cohen’s $s$3, and attributes 61.2% of gap errors to filtering or logic and only 7.7% to dialect syntax (Perlitz et al., 8 May 2026). This directly challenges the misconception that dialect-aware planning is mainly a matter of syntax adaptation.

4. Planning architectures and algorithmic strategies

Several design patterns recur across the literature. The first is explicit planner–executor separation. OraPlan-SQL uses a two-agent system in which a Planner agent produces stepwise natural-language plans and a SQL agent converts those plans into executable SQL (Liu et al., 27 Oct 2025). On English development data, removing the planner drops execution accuracy from 72.12% to 64.42%, while retaining the planner but removing its meta-prompted guidelines drops it further to 44.23%; on Chinese development data, guidelines raise execution accuracy from 49.04% to 79.81% (Liu et al., 27 Oct 2025). The planner is further improved by feedback-guided meta-prompting: failure cases are clustered with human input, an LLM distills corrective guidelines, and those guidelines are inserted into the planner prompt. For arithmetic, the planner is instructed to state formulas such as percentage = 100.0 * part / total; for hypotheticals, it must output explicit Counterfactual Condition and Action After Condition lines (Liu et al., 27 Oct 2025).

The second pattern is canonicalization through knowledge-grounded operator specification. Dial first constructs an NL-LQP and then converts dialect-sensitive operators into functional categories backed by HINT-KB, whose declarative function repository $s$4 stores usage scenarios, semantic specifications, and dialect-specific implementations, and whose procedural constraint repository $s$5 stores implicit execution constraints and repair rules (Zhang et al., 8 Mar 2026). This makes function selection a retrieval problem keyed by logical intent rather than a memorization problem inside model parameters. Dial then applies an execution-driven debugging loop, semantic verification against the immutable plan, and incremental knowledge consolidation via primitives of the form

$s$6

that are routed back into $s$7 or $s$8 depending on similarity to the plan (Zhang et al., 8 Mar 2026).

The third pattern is structural search or optimization over plan space. PlanRAG decomposes exploratory reasoning problems into atomic queries and builds logical query trees using dynamic programming. Its cost function is

$s$9

with best results at $s$0, and $s$1 computed from embeddings of a textualized tree and the original query (Xu et al., 1 Jul 2026). A.DOT similarly treats planning as a constrained DAG generation problem, but emphasizes validation and repair: structural checks, dependency hygiene, acyclicity, and LLM-based semantic validation are enforced before execution, with a DataOps subsystem diagnosing errors, fixing local issues, or replanning if needed (B et al., 15 Mar 2026).

The fourth pattern is dialect-specific specialization combined with shared semantics. MoMQ does not expose an explicit logical plan, but its architecture decomposes the problem internally into shared experts and dialect expert groups. The training objective

$s$2

combines generation loss with a Dialect Router Loss and an Expert Balance Loss, so that shared experts capture dialect-agnostic semantics while dialect experts realize that semantics into MySQL, PostgreSQL, Cypher, or nGQL (Lin et al., 2024). This suggests an implicit planner–realizer separation at the representation level even when no explicit plan is surfaced.

Finally, several papers emphasize schema-side or backend-side support for planning. “The Case for Text-to-SQL Friendly Logical Database Design” frames logical design itself as an optimization target, with schema abstraction $s$3, schema partitioning $s$4, and schema renaming $s$5 used to make relational structure, relevance, and semantics easier for an LLM to plan over (Zhang et al., 2 Jun 2026). Text-to-query-plan work on large tables uses a three-level vector index over columns, clusters, and tables to prune the schema presented to the planner and thereby mitigate context-length limits (Zhang et al., 26 Aug 2025). A plausible implication is that dialect-aware logical planning is not solely a model-side problem; it also depends on what logical surface the schema and backend expose to the planner.

5. Evaluation paradigms and empirical evidence

The empirical literature consistently favors structure-aware and execution-based evaluation. Dialect2SQL evaluates baseline code-specialized LLMs on a random subset of 697 Darija questions using BLEU, SQAM, and TSED. StarCoder2-7B is best, with BLEU $s$6, SQAM $s$7, and TSED $s$8, while CodeT5-2B scores $s$9, $d$0, and $d$1, respectively (Chafik et al., 20 Jan 2025). These low scores on dialectal input indicate that end-to-end LLMs without explicit dialect-aware planning struggle even before cross-engine dialect realization is considered.

Competition and benchmark results reinforce the value of explicit planning. OraPlan-SQL ranks first on the Archer test set with English EX 54.96% and Chinese EX 56.67%, exceeding the runner-up by +6.3 and +12.6 execution-accuracy points, respectively, while maintaining over 99% SQL validity (Liu et al., 27 Oct 2025). Dial reports that, on DS-NL2SQL, it improves translation accuracy by 10.25% and dialect feature coverage by 15.77% over state-of-the-art baselines, and achieves overall Exec 97.33% and overall Acc 48.39% under strict cross-dialect criteria (Zhang et al., 8 Mar 2026). In the hybrid QA setting, A.DOT reaches 71.0 correctness and 73.0 completeness on HybridQA dev, compared with 56.2 and 62.3 for Standard RAG, and loses most when its DataOps repair loop is removed (B et al., 15 Mar 2026).

Planning-oriented intermediate languages and operator graphs also show competitive performance. QPL-based semantic parsing obtains 63.4% execution match overall on Spider dev, and 73.6% when considering only executable predicted queries, while remaining markedly stronger than direct CTE prediction by GPT-3.5 at deeper QPL depths (Eyal et al., 2023). Text-to-query-plan work on Spider reports 70.34 exact match with schema and GPT-4o, competitive with DIN-SQL’s 74.20, and answers 16 of 20 manually designed large-table scientific questions correctly on a dataset with 266,033 rows and 8,058 features (Zhang et al., 26 Aug 2025).

Dialect robustness, however, remains difficult. PolySQL’s cross-dialect study across 16 models and six dialects finds weak per-query agreement between SQLite and enterprise dialects, a significant dialect difficulty hierarchy, and dominant logical errors in gap cases (Perlitz et al., 8 May 2026). RISE shows that dialect-aware query reduction plus rule extraction can substantially improve SQL dialect translation for complex source queries, reaching 97.98% accuracy on TPC-DS and 100% on SQLProcBench, outperforming both traditional rule-based tools and direct LLM-based translation (Xie et al., 9 Jan 2026). SQLFlex, on the parsing side, reports 91.55% to 100% query round-trip across eight dialects and high semantic match on tables, columns, joins, and operators, indicating that robust dialect parsing is feasible when clause-level and expression-level segmentation are used instead of direct end-to-end AST generation (An et al., 17 Mar 2026).

System or benchmark	Main planning object	Representative result
Dialect2SQL	Darija NLQ to SQL under cross-lingual schema-linking	StarCoder2-7B: BLEU 0.171, SQAM 0.403, TSED 0.224 (Chafik et al., 20 Jan 2025)
OraPlan-SQL	Stepwise natural-language plan $d$2	Archer test: EN EX 54.96%, ZH EX 56.67%, VA > 99% (Liu et al., 27 Oct 2025)
Dial	NL-LQP plus dialect-aware operator specification	+10.25% Acc and +15.77% DFC over baselines on DS-NL2SQL (Zhang et al., 8 Mar 2026)
PolySQL	Dual-execution cross-dialect evaluation	10.1% average drop from SQLite to other dialects (Perlitz et al., 8 May 2026)

Taken together, these results support a consistent conclusion: explicit logical planning improves robustness, but evaluation must be execution-based and dialect-specific. String similarity or single-dialect accuracy does not adequately measure dialect-aware planning quality.

6. Limitations, controversies, and research directions

Several limitations recur across the surveyed work. Coverage remains incomplete. Dialect2SQL only translates the training portion of BIRD and does not define a dedicated Darija test split (Chafik et al., 20 Jan 2025). DS-NL2SQL focuses on dialect-specific select-style queries and relies on documentation-driven knowledge extraction for HINT-KB (Zhang et al., 8 Mar 2026). PolySQL evaluates dialect portability over the intersection of features shared with SQLite, not full native-dialect mastery (Perlitz et al., 8 May 2026). QPL covers more than 99% of Spider but is still tied to a restricted operator set derived from SQL Server execution plans (Eyal et al., 2023).

Another limitation is the tension between free-form plans and formal guarantees. OraPlan-SQL’s plans are natural language guided by prompts rather than a typed formal language (Liu et al., 27 Oct 2025). Dial’s NL-LQP is explicit and structured, but semantic verification still presumes that the initial logical plan is trustworthy (Zhang et al., 8 Mar 2026). A.DOT and PlanRAG add validation and repair, yet their planners are still LLM-driven rather than formally verified search procedures (B et al., 15 Mar 2026). This suggests a continuing trade-off between expressivity and verification: natural-language plans are easier to generate and inspect, but typed or algebraic representations may be easier to validate compositionally.

A third issue is that schema, metadata, and evaluation design materially shape planning outcomes. Logical database design work shows that schema abstraction, partitioning, and renaming can improve execution accuracy by up to 4.2% on BIRD-Union and Spider-Union, but also cause regressions when partitions prune away necessary tables or renamings bias the model toward plausible but incorrect relations (Zhang et al., 2 Jun 2026). PolySQL likewise shows that backend isomorphism and normalized result comparison are prerequisites for meaningful cross-dialect evaluation (Perlitz et al., 8 May 2026). A plausible implication is that dialect-aware planning research should treat schemas, benchmarks, and evaluation infrastructure as first-class components of the planning problem.

The major research directions are correspondingly clear. One is richer intermediate representations: semi-formal logical plan languages, typed DSLs, or graph-based operator systems that preserve the transparency of planning-centric approaches while reducing ambiguity (Liu et al., 27 Oct 2025). Another is stronger cross-lingual and cross-dialect schema-linking, especially for low-resource dialects such as Darija and for multilingual entity resolution under transliteration mismatch (Chafik et al., 20 Jan 2025). A third is automatic rule induction and repair: RISE extracts reusable dialect translation rules from simplified queries, while A.DOT and Dial update their knowledge stores from repair traces, suggesting a broader shift toward feedback-driven accumulation of dialect-specific planning knowledge (Xie et al., 9 Jan 2026). Finally, cross-backend generalization remains open. QPL, operator-graph planning, and DAG orchestration all point toward dialect-neutral logical cores with backend-specific renderers or executors, but the literature has not yet converged on a single formalism that simultaneously spans low-resource natural-language dialects, heterogeneous SQL dialects, and non-SQL backends (Eyal et al., 2023).

In this sense, dialect-aware logical query planning is best understood not as a narrow variant of text-to-SQL, but as a general architecture for separating intent recovery, logical structuring, dialect-specific realization, and execution-based validation. The surveyed work shows that this separation is already technically productive, but also that robust multi-dialect planning still depends on better intermediate forms, richer knowledge grounding, and evaluation methods that measure semantics rather than syntax.