PaperlayerView exact revision on arXiv

Source-linked AI summary

Automating Database-Native Function Code Synthesis with LLMs

Wei Zhou, Xuanhe Zhou, Qikang He, Guoliang Li, Bingsheng He, Quanqing Xu, Fan Wu

arXiv:2604.06231v1cs.DBcs.AIcs.CLcs.IRcs.SE

TL;DR

General-purpose code synthesis frameworks do not fully use database-specific function structure, while synthesizing native functions requires handling declarations, internal units, and references. DBCooker characterizes those structures and applies database-aware synthesis operations; experiments show it outperforms state-of-the-art methods and supports new function synthesis.

  • Problem

    Existing code synthesis frameworks struggle to use database function information to identify internal relations, reuse complex code, and validate diverse argument edge cases.

    Source: §5 · p. 11

  • Method

    DBCooker characterizes function declarations, implementation units, and cross-unit references, then applies database-aware synthesis operations and adaptive tool orchestration.

    Source: §3 · p. 7, §9 · p. 23

  • Results

    Experiments on three databases show DBCooker outperforms state-of-the-art methods and effectively supports new function synthesis.

    Source: §9 · p. 24

  • Takeaways & Limitations

    Database-native function synthesis can be supported by an approach tailored to database codebase structure.

    Source: §3 · p. 7, §9 · p. 24

    Massive, fragmented database codebases make relevant units difficult to identify; including the entire codebase in long-context reasoning is costly and may still miss them.

    Source: §9 · p. 24

Abstract

from arXiv · show

Database systems incorporate an ever-growing number of functions in their kernels (a.k.a., database native functions) for scenarios like new application support and business migration. This growth causes an urgent demand for automatic database native function synthesis. While recent advances in LLM-based code generation (e.g., Claude Code) show promise, they are too generic for database-specific development. They often hallucinate or overlook critical context because database function synthesis is inherently complex and error-prone, where synthesizing a single function may involve registering multiple function units, linking internal references, and implementing logic correctly. To this end, we propose DBCooker, an LLM-based system for automatically synthesizing database native functions. It consists of three components. First, the function characterization module aggregates multi-source declarations, identifies function units that require specialized coding, and traces cross-unit dependencies. Second, we design operations to address the main synthesis challenges: (1) a pseudo-code-based coding plan generator that constructs structured implementation skeletons by identifying key elements such as reusable referenced functions; (2) a hybrid fill-in-the-blank model guided by probabilistic priors and component awareness to integrate core logic with reusable routines; and (3) three-level progressive validation, including syntax checking, standards compliance, and LLM-guided semantic verification. Finally, an adaptive orchestration strategy unifies these operations with existing tools and dynamically sequences them via the orchestration history of similar functions. Results show that DBCooker outperforms other methods on SQLite, PostgreSQL, and DuckDB (34.55% higher accuracy on average), and can synthesize new functions absent in the latest SQLite (v3.50).

1 Introduction

DBCooker addresses growing demand for database-native functions by analyzing function composition and internal references, synthesizing linked units, and adapting its workflow to functions of varying complexity.

Motivation

  • Expanding database-native function sets support new application scenarios and migrations, yet proprietary-function refactoring imposes substantial development costs.The passage reports refactoring accounts for 30%–60% of migration budgets and requires 40–80 hours per 1,000 code lines; function counts rose from 237 to 630 in PostgreSQL, 60 to 666 in DuckDB, and 52 to 143 in SQLite across the cited versions.Source: §1 · p. 2

Limitations of Existing Methods

  • Existing general-purpose methods can omit required units, search unrelated files, skip verification, and apply static from-scratch workflows without reusing related implementations.The examples include Qwen Code omitting an interval-input unit and Claude Code spending time scanning unrelated files rather than validating date_trunc() across inputs.Source: §1 · pp. 2–3

Challenges

  • Native-function synthesis must identify multiple SQL-to-code units, recover essential internal references, and adapt between simple wrappers and complex custom logic.For PostgreSQL date_trunc(), using references to implement four registered units reduces required code lines by approximately 94.95% versus implementing from scratch, which requires 6,235 lines and 225 functions across two-hop invocations.Source: §1 · pp. 2–4

Our Methodology

  • DBCooker combines declaration-based function characterization, structured pseudo-plan generation, reference-aware fill-in-the-blank synthesis, progressive validation, and adaptive orchestration informed by similar workflow trajectories.Its validation progresses through syntax checking, standards compliance, and LLM-guided checking; orchestration combines LLM-driven decisions with reuse of similar workflow trajectories.Source: §1 · p. 4

Contributions

  • DBCooker achieves 34.55% higher accuracy on average than state-of-the-art methods such as Claude Code across three databases, and adds functions absent from SQLite v3.50.The paper reports evaluation on SQLite, PostgreSQL, and DuckDB.Source: §1 · p. 4

2 Preliminary

The section defines database-native functions and frames their synthesis as implementing integrated kernel code from a SQL-level specification. Its pilot study identifies dense references, inefficient repository exploration, and frequent declaration errors as challenges.

2.1 Database Native Functions

  • A database-native function combines a declaration, new executable function units, and existing reference units behind a unified SQL-level interface.Units may contain multiple code blocks; the date_trunc() example includes four new units and reusable PostgreSQL routines.Source: §2.1 · pp. 4–5

2.2 Database Native Function Code Synthesis

  • Synthesis generates the necessary function-unit code from a SQL-level specification, integrates essential references, and must satisfy compliance requirements and database test cases.The specification can include the function name, description, input arguments, output types, and SQL examples.Source: §2.2 · p. 5

2.3 Pilot Study

  • 2619.56, 1594.65, and 872.32 references per file contrast with 13.73, 47.58, and 33.11 per function unit across three database repositories.The disparity motivates accurately identifying the small set of references needed during synthesis.Source: Figure 2 · p. 6
  • Claude Code [1] spent 63.70% of its time searching repositories and reading files, versus 4.95% updating files to generate code.The study argues that generic agent frameworks underemphasize database-specific structure, code construction, and validation.Source: Figure 2 · p. 6
  • 81.76% of errors from Claude Sonnet 4.5 and Claude Code on PostgreSQL function synthesis were declaration errors.Observed errors included redeclarations and function references with mismatched arguments; test-case failures also occurred.Source: Figure 2 · p. 6, §2.3 · p. 7

3 DBCooker Overview

DBCooker adapts function synthesis to database codebases by modeling their structure and dependencies, then coordinating specialized planning, coding, validation, and orchestration operations.

Function Characterization

  • Function characterization collects declarations from documentation and system catalogs, identifies internal units for SQL functions, and refines cross-unit references for synthesis.It uses dependency-graph analysis to distinguish reusable shared auxiliary units from function-specific units.Source: §3 · pp. 7–8

Function Synthesis Operations

  • Pseudo-code planning uses function metadata, database hierarchy, and matched reference units to generate and rank structured implementation skeletons.Candidate plans contain placeholders for variables, function bodies, and return expressions; pruning favors brevity and convention adherence.Source: §3 · p. 8
  • Progressive synthesis instantiates partially matched templates and uses probabilistic adaptation for blank-filling or generation from scratch, followed by three-stage validation.Validation checks syntax, database convention compliance, and semantics using database tests augmented with generated cases across input types and edge cases.Source: §3 · p. 8

Adaptive Function Synthesis

  • Adaptive orchestration unifies callable tools and combines an LLM controller with historical workflow memory to select steps for each synthesis task.The accumulated trajectories guide and accelerate synthesis of similar functions.Source: §3 · p. 8

4 Function Characterization

DBCooker characterizes database-native functions through deterministic graph-based analysis, addressing declarations distributed across sources, database-specific implementation conventions, and structural reuse and dependencies between function units.

4.1 Function Declaration Collection

  • Official documentation and internal catalogs are parsed into a unified JSON representation combining SQL-level semantics with implementation-level argument and return-type specifications.For PostgreSQL’s date_trunc, documentation supplies its description and example, while catalog extraction supplies its argument and return types.Source: §4.1 · p. 9

4.2 Distinctive Function Unit Identification

  • Graph-based extraction traces function references from a SQL keyword to implementation units, then pairwise pruning identifies reusable code patterns across declaration-grouped functions.Units are compared along reference paths after identifier abstraction; variable blocks become placeholders, and multi-round comparisons select frequently occurring pruned units for synthesis.Source: §4.2 · pp. 9–10

4.3 Cross-Unit Reference Analysis

  • Cross-unit reference analysis extracts dependencies through static analysis, prunes reference units to retain essential context, and allows further expansion during synthesis.For example, ScalarFunctionSet retains its declaration list while detailed method implementations are omitted; additional references can be retrieved on demand.Source: §4.3 · p. 11

5 Function Code Synthesis Operations

DBCooker addresses limits of direct, from-scratch synthesis and LLM-dependent validation with structured coding plans, progressive fill-in-the-blank synthesis, and three-level validation.

5.1 Pseudo-based Coding Plan Generation

  • Coding plans map registered SQL-level function units and database hierarchy into explicit decompositions and references, replacing opaque LLM reasoning with an informative implementation skeleton.Each plan identifies decomposed function units and referenced units within the database.Source: §5.1 · p. 11

5.1.1 Candidate Plan Generation

  • Candidate plans match metadata to same-category functions, then specify per-input-type units, code-block logic, file paths, and reusable references; parallel pseudo-plans are scored to reduce errors.The plan-generation process targets mistakes such as nonexistent macros and omitted input-processing branches.Source: §5.1.1 · pp. 11–12

5.1.2 Scoring-based Plan Filtering

  • Plan filtering scores reference correctness and simplicity, removes incorrect units, and rejects plans below a threshold such as 0.5.The score weights incorrect references, incorrect file locations, and the number of listed units at 0.4, 0.4, and 0.2, respectively.Source: §5.1.2 · p. 12

5.2 Progressive Code Synthesis

  • Fill-in-the-blank synthesis reuses representative same-category function units, generates only distinctive logic where possible, and merges parallel candidates by self-consistency.In DuckDB’s date-part example, the model generates type-specific units and adds them to DatePartFun::GetFunctions rather than rebuilding registration units.Source: §5.2 · p. 12
  • The fill-in-the-blank model starts with adoption probability 1 and decays it exponentially after failures, eventually rolling back to exploratory from-scratch synthesis.This adaptation can discard flawed plans, such as those with nonexistent macros or incorrect file paths.Source: §5.2 · p. 13

5.3 Three-Stage Code Validation

  • Progressive validation checks single-file syntax, multi-file database compliance and builds, then runtime semantics using LLM-generated SQL tests informed by expertise, existing suites, and decomposed code blocks.Syntax checks can use language-specific parsers such as ANTLR; compliance checks can invoke database-specific commands such as PostgreSQL’s make install.Source: §5.3 · p. 14

6 From Static Function Synthesis to Adaptive Tool Orchestration

DBCooker replaces fixed synthesis pipelines with memory-augmented orchestration that sequences tools according to function-specific complexity and synthesis context. It standardizes synthesis operations as callable tools and records tool-use trajectories to guide later synthesis of similar functions.

6 From Static Function Synthesis to Adaptive Tool Orchestration

  • DBCooker shifts from fixed synthesis pipelines to adaptive orchestration, sequencing operations using retrieved trajectories of similar functions and synthesis context.The shift addresses the diversity of database-native functions, from standard-library wrappers to functions requiring specialized processing logic.Source: §6 · p. 14

6.1 Operation-as-Tool Abstraction

  • Each synthesis operation is encapsulated as a callable tool with metadata, core logic, and routing modules, alongside common utilities and LLM-based operations.The routing module returns outputs in a standardized format that can be fed into the LLM context; the tool set also includes strategies such as majority-vote sampling and post-synthesis self-reflection.Source: §6.1 · pp. 14–15

6.2 Tool-based Stepwise Function Synthesis

  • The stepwise synthesis framework retrieves category-matched orchestration trajectories, lets the LLM choose tools iteratively, and stores completed trajectories for future guidance.Memory records function metadata, tool sequences and usage statistics, and an LLM-generated summary; entries are retained when they add statistical evidence, and retrieval selects minimum-, median-, and maximum-tool-count examples.Source: §6.2 · pp. 15–16

7 Experiments

The experiments evaluate DBCooker across SQLite, PostgreSQL, and DuckDB using compilation/integration and test-passing metrics. They compare synthesis methods, examine difficulty and category effects, ablate components, and test new SQLite functions.

7.1 Experiment Settings

  • The evaluation tests 75 SQLite, 145 PostgreSQL, and 128 DuckDB functions, comparing LLM-, CodeRAG-enhanced, and agent-based methods using compliance and result accuracy.Compliance accuracy measures successful compilation and integration; result accuracy measures passing all test cases and yielding expected results.Source: §7.1 · p. 16

7.2 Overall Performance

  • Across three mainstream databases, DBCooker achieved Acc_EXE and Acc_RES scores of 78.90% and 65.19%, respectively, outperforming other methods by average margins of 124.37% and 149.68%, respectively.The authors attribute this improvement to three database-aware modules integrated in DBCooker.Source: §7.2 · p. 17
  • CodeRAG improves LLM-based accuracy by 50.56% on average; DBCooker has the fewest declaration-related errors, and +Hint agents remain 22.56% less accurate than DBCooker.The +Hint agents receive correct paths, declarations, and references, yet still produce undefined references and type-related semantic errors; DBCooker’s progressive validation helps address such failures.Source: §7.2 · pp. 17–18, Figure 8 · p. 18, Figure 9 · p. 19

7.3 Fine-Grained Analysis

  • 78.44% Acc_EXE and 62.60% Acc_RES are DBCooker’s difficulty-group accuracies, averaging 133.06% and 150.80% above other methods; on HARD functions, it reaches 68.97%, 197.10% above them.LLM- and RAG-based methods’ Acc_EXE and Acc_RES average 35.30% and 32.16% on EASY functions, falling to 22.02% and 18.90% on HARD functions.Source: §7.3 · p. 19, Table 2 · p. 20
  • Across four PostgreSQL function categories, DBCooker’s Acc_EXE ranges from 89.19% to 96.67%, with overall accuracy 151.11% above other methods.It uses category information to identify distinctive units and retrieve same-category references, whereas other approaches may start from scratch or repeatedly search the repository.Source: §7.3 · p. 20, Table 2 · p. 20

7.4 Ablation Study

  • With all proposed components, DBCooker improves Acc_EXE and Acc_RES by 42.14% and 37.50% on average; removing three-stage validation drops PostgreSQL Acc_EXE from 78.62% to 6.9%.The authors attribute validation’s importance to PostgreSQL’s cross-file dependencies and multi-branch execution paths; syntax/compliance and semantic checks help refine date_trunc() implementations.Source: §7.4 · p. 21, Table 3 · p. 21
  • Disabling planning raises PostgreSQL Acc_RES from 5.52% to 7.59%, but the authors report this 2.07% difference alongside a 37.50% overall improvement from the interacting components.Plans can include logic branches such as tsrange handling; without validation to catch inapplicable branches, plans and validation work together to address complex logic.Source: §7.4 · pp. 21–22, Table 3 · p. 21

7.5 New Native Function Synthesis

  • For new SQLite functions, DBCooker implements and registers required units, incorporates repository reference units, and adapts declarations and code to function categories.Examples include implementing covar_pop()’s step, finalize, and inverse units; using SQLite helpers in bool_or and regexp_split_to_array; and distinguishing WAGGREGATE from FUNCTION. Other methods leave units or references undefined, or fail after irrelevant searches.Source: §7.5 · pp. 22–23, Table 4 · p. 22

8 Related Work

Related work spans general code generation, UDF optimization, runtime code generation, and database migration. These approaches differ from DBCooker in scope, focusing on code generation limits, UDF rewriting, temporary execution code, or SQL translation rather than persistent kernel-level function synthesis.

General Code Generation

  • Prompt-, agent-, and training-based code-generation methods remain limited for database-native function synthesis, which demands precise searches, function references, and adaptation to input types and database constraints.The passage ties this limitation to results in Section 7.Source: §8 · p. 23

UDF Optimization

  • Froid rewrites imperative UDFs into relational algebra for SQL optimization, while Tuplex compiles Python UDFs with a fallback path; neither implements kernel-level code.Tuplex optimizes the common case and handles exceptions through fallback.Source: §8 · p. 23

Runtime Code Generation

  • HyPer and Weld generate temporary machine code for query or workflow execution, unlike DBCooker’s reusable, persistent native functions.HyPer uses LLVM-based compilation and a data-centric push model; Weld uses a shared intermediate representation to reduce data movement and generate parallel code.Source: §8 · p. 23

Database Migration

  • CrackSQL [50] iteratively repairs SQL dialect translations after local execution failures, while PARROT [51] benchmarks cross-system translation of system-specific syntax.These studies highlight the complexity and manual effort involved in reimplementing native functions across database systems.Source: §8 · p. 23

9 Conclusion and Future Work

DBCooker is presented as the first LLM-based system for automatic database-native function synthesis, combining function characterization, database-aware synthesis operations, and adaptive tool orchestration. Experiments across three databases show that it outperforms state-of-the-art methods and supports new function synthesis.

Conclusion

  • Experiments on three databases show DBCooker outperforms state-of-the-art methods and effectively supports synthesis of new functions.Source: §9 · p. 24

Future Work

  • For massive, fragmented codebases, DBCooker identifies relevant scattered function units that long-context reasoning alone may overlook [33] [40].PostgreSQL exceeds one million lines of code, with declarations and implementations separated across files.Source: §9 · p. 24
  • Because probabilistic LLM generation cannot guarantee mission-critical correctness, DBCooker enforces structural templates and correctness constraints through pseudo-plans and three-stage validation [19] [48].Source: §9 · p. 24
  • To handle database-version changes without retraining, DBCooker retrieves version-specific implementation routines and enforces them through adaptive orchestration [30].Source: §9 · p. 24

Related papers

Loading 2604.06231v1…