Documentation
¶
Overview ¶
Package dmltarget answers one question about a DML statement: which table does it write?
It exists for a specific gap in the lineage analyzers. Lineage is a column-level relation, so a statement whose written values come from no column at all yields no relation in any dialect — `INSERT INTO t (a, b) VALUES (?, ?)`, or a `DELETE` that references no column. Nothing in the analysis then names the table being written, so the statement can neither be classified as a write nor drawn with an edge to its target. See .agents/docs/application-sql-ingestion.md, "Classification and the table-level edge".
The caller is expected to ask only because the analysis came back empty. That population is narrow: an UPDATE answers with `t.* -> t.a` even for a constant assignment, every DDL statement has a real target, a SELECT writes nothing, and a multi-table DELETE or UPDATE over a join references columns. None of those need this package. Where it can read a table it still answers — the caller simply never asks — and where it cannot it returns ErrNoTarget rather than a guessed name.
Index ¶
Constants ¶
This section is empty.
Variables ¶
var ErrNoTarget = errors.New("no DML write target")
ErrNoTarget reports a statement this package cannot attribute a write to.
Functions ¶
func Targets ¶
Targets returns the tables a statement writes, named as the statement named them. InstanceID is always empty: a statement only ever names an object down to database/schema level, and catalog.AnalysisContext.Complete fills in the rest — the same rule the analyzers and AnalyzeSQL follow.
A name the parser could not read is never invented: an empty target returns ErrNoTarget rather than a zero identifier.
Types ¶
This section is empty.
Source Files