wadjet

func Attach ¶ added in v0.18.20

func Attach(cat *catalog.Catalog) *DB

Attach wraps an ALREADY-INITIALIZED catalog as a DB, without creating a second catalog or re-running Init.

It exists so a process that already owns a *catalog.Catalog — the HTTP API server in coordinator mode — reaches DML through the SAME implementation the embedded and pgwire doors use, instead of keeping its own copy of the executors. internal/server carried an independent INSERT/UPDATE/DELETE that had drifted into the same defects as this package's (#815): an unresolved INSERT column list (#814), the marker/manifest window (#691), the literal kind discarded in SET (#690) — and no MERGE at all. A fix written once has to be reachable from both doors, and this is that reach.

The returned DB owns no background goroutines (Open's alert scheduler is not started), so it needs no Close; the caller keeps ownership of the catalog.

func Open ¶

func Open(ctx context.Context, cfg Config) (*DB, error)

Open creates and initializes a new Wadjet database.

package main

import (
	"context"

	"github.com/derekmwright/wadjet/internal/storage/objstore"
	"github.com/derekmwright/wadjet/wadjet"
)

func main() {
	ctx := context.Background()

	store, _ := objstore.NewFileStore("/var/lib/wadjet") // or NewMinIOStore(...) for S3
	db, _ := wadjet.Open(ctx, wadjet.Config{Store: store, Bucket: "analytics"})
	res, _ := db.Query(ctx, "SELECT src_ip, SUM(bytes_in) FROM flow_logs GROUP BY 1")

	_ = res
	defer db.Close()
}

Output:

func ResolveDMLSetClauses ¶ added in v0.18.5

func ResolveDMLSetClauses(clauses []plansql.SetClause, target plansql.DMLTarget, schema []parquet.Column) ([]DMLAssignment, error)

ResolveDMLSetClauses resolves an UPDATE's SET list against the table's schema, before anything executes.

Two defects met here (#678). `UPDATE t SET nosuchcol = 1` reported "UPDATE 1": the assignment was dropped into a map nothing read and the matched rows were rewritten unchanged, where PostgreSQL raises 42703. And the value was read ONLY as a literal, through a converter whose STRING arm cannot fail — so `SET s = UPPER(s)` stored the seven characters "UPPER(s)" into the column. PostgreSQL evaluates it, and so does this now.

Whether a SET value is a literal is decided from its PARSE, not from whether a conversion succeeded, because for a STRING column the conversion always succeeds and the literal path always won. A `*plansql.Lit` takes the constant path — which is what keeps #647's declaration checks (ConvertValueForColumn's DECIMAL precision, the temporal accept-sets) running on the values that have them; anything else is compiled and evaluated per row against the file's own batch, which carries the table's declared types.

A SET VALUE resolves against the same relation name the WHERE does, so `UPDATE pr AS a SET n = a.n + 1` reads a.n and `SET n = pr.n` under that alias is 42P01 — PostgreSQL's answer for both (#686).

func BuildDMLPredicate ¶ added in v0.18.5

func BuildDMLPredicate(target plansql.DMLTarget, schema []parquet.Column, sub *DMLSubqueryEnv) (DMLPredicate, error)

BuildDMLPredicate compiles a DML WHERE clause against a table's schema. An empty clause compiles to nil — "every row".

The SCHEMA is a parameter, not an optional extra, because the DML doors do not go through the planner and so had no name-resolution step at all: `UPDATE t SET n = 1 WHERE nosuchcol = 1` compiled fine, evaluated to NULL on every row and reported "UPDATE 0", where PostgreSQL raises 42703 (#678). Every column the clause names is resolved here, before anything executes.

It is exported because MatchDMLRows is the other half of the contract and is the one that must be used to RUN a predicate. (The HTTP door is no longer a second caller: since #815 it reaches the executors through DB.ExecuteParsed like everything else.)

A SUBQUERY IN A DML PREDICATE (#688).

`DELETE … WHERE id IN (SELECT …)`, `NOT IN (SELECT …)`, a scalar subquery and a correlated `EXISTS` were all 0A000 here. The reason was structural: this function is not a planner. It parsed, resolved the column names against the target's schema, and called `expr.Compile` with a NIL runner and no outer scope, so every planner-resident guarantee was absent on this door.

It is answered now, and the shape of the answer is what makes it not the bounded repair ADR-0031 forbade. That one was `expr.CompileWithRunner` — a runner and nothing else — which closes `IN`, `NOT IN` and the scalar subquery and leaves CORRELATED `EXISTS` refused, because a compile site with no outer scope cannot classify a subquery as correlated in the first place. The scope is the missing half, and a DML statement has the simplest one there is: exactly ONE relation, the target, under its alias when it has one and its own name when it does not, with the columns of the schema this function was already handed. Given that scope, `expr.CompileWithScopeResolver` builds the same correlated evaluators the query path builds, and `EXISTS (SELECT 1 FROM s WHERE s.id = t.id)` — the shape #688's own body names first — answers.

THE PREDICATE IS STILL COMPILED AND NOT PLANNED, which is ADR-0031's position and is unchanged: the door still walks its files and evaluates the clause per row, and the structural DELETE-as-a-planned-SELECT design that record blocks on a projectable row identity is still blocked and still unnecessary here. What is planned is the SUBQUERY, through the ordinary SELECT path.

TWO CONSEQUENCES ARE THE QUERY PATH'S, INHERITED RATHER THAN INVENTED. An uncorrelated subquery is executed ONCE and memoized; a correlated one is re-run per outer row with the outer values substituted as typed literals (ADR-0021 §1e), so an outer value with no literal spelling is 0A000 there as it is in a SELECT. And a subquery that cannot be RUN fails the statement rather than deciding it (§1c) — which on a WRITE door is the difference between refusing and deleting the wrong rows.

THE SNAPSHOT. The subquery runs against the manifest the catalog holds while the statement is scanning, and a DML statement commits its markers at the end (ADR-0030), so a subquery over the TARGET TABLE reads the pre-statement state — which is what PostgreSQL does. `DELETE FROM t WHERE id IN (SELECT id FROM t WHERE …)` is in the census with PostgreSQL's answer beside it.

THE EMPTY-PREDICATE BACKSTOP. A nil predicate is the widest answer this function can give — every row of the table — so "the statement had no WHERE" and "the parser dropped the statement's WHERE" must not look the same here. They did, and the second one emptied tables: a DELETE with an aliased table returned an empty WhereSQL and deleted everything (#686). The check below is not about that spelling, which the parser now reads; it makes the CLASS unreachable, so the next clause any parser path fails to carry fails the STATEMENT instead of widening it (ADR-0019, correctness-fix protocol item 8: loud beats plausible).