feat: alternate PRQL-native implementation of append by:name

[kgutwin]

See #5165 for background discussion.

This PR adds a PRQL-native implementation of append by:name which is dialect-independent. This is a counterpart (but not exclusive to) PR #6037 which would add dialect-specific support for UNION ALL BY NAME.

This PR has three main categories of changes:

1. The std._append_by_name function was added, and the internal definition of append was extended to parse the by: named argument. When by:name is provided, it generates a FuncCall expression to invoke std._append_by_name.
2. Support was added in semantic/resolver/expr.rs for wildcard expansion of relations via their lineage information. This seemed to be necessary in order to implement _param.bottom.* within the std._append_by_name function.
3. Two new tuple functions were added: tuple_uniq and tuple_reverse. I ended up not needing to use tuple_reverse but I left it in anyway in hopes that someone will find it useful. tuple_uniq takes a tuple which may have duplicate entries (by alias or by Ident name) and returns either the earliest or latest seen instance of a given name, depending on the value of the take: named argument.

Updates to the documentation are still pending, and there's also a potential question related to lineage that I may work on exploring.

[prql-bot]

Nice work — the _append_by_name formulation in std.prql is a clever, fully dialect-independent approach, and the column-alignment via tuple_uniq reads cleanly.

CI is red because Clippy runs with -D warnings and flags two issues, both in this diff (see inline suggestions):

• expr: &Box<pl::Expr> triggers clippy::borrowed_box — &pl::Expr works via deref coercion at the call site.
• The trailing return Err(...) in resolve_ident_wildcard triggers clippy::needless_return.

A couple of non-blocking notes for whenever you pick this back up (the PR description already flags docs/lineage as pending):

• tuple_reverse is added to std.prql and the resolver but, per the description, isn't used by anything. Adding it permanently expands the language surface speculatively — worth dropping it unless there's a concrete consumer, since it'd otherwise need docs/tests of its own.
• Several log::trace!/log::debug! calls and the new Module::all_names helper ("Useful for debugging") look like instrumentation left over from development (e.g. the per-ident ... candidates dump in expr.rs, the find_input_by_name trace in module.rs, the tuple-intersection trace in types.rs). They're trace-gated so harmless at runtime, but worth pruning the ones that were just for bring-up before merge.

[kgutwin]

@max-sixty This PR should be ready for your review -- thanks!

[max-sixty]

hi @kgutwin !

I had a look, would like to spend more time looking, but also trust you so don't feel I need to understand every line.

I did lean on an LLM to poke at parts, a few cases we found below. It's possible that we are missing something though! Let me know if so...

---

1. An unnamed column is silently dropped.

from a
select {x, x + 1}
append by:name (from b | select {x, y})

compiles to (note x + 1 from a has vanished):

SELECT x, NULL AS y FROM a
UNION ALL
SELECT x, y FROM b

Plain append keeps it as x + 1 AS y, so the by-name path loses data the by-position path preserves.

2. Unknown schemas silently fall back to a position-union.

from a
append by:name (from b)

gives plain SELECT * FROM a UNION ALL SELECT * FROM b. The by:name is ignored, so you get exactly the position semantics it was meant to replace, with no indication.

3. One side defined and one not gives a confusing internal error.

from a
select {x, y}
append by:name (from b)

errors with cannot append two relations with non-matching number of columns / top has 2 columns, but bottom has 3, which exposes _append_by_name's internal top/bottom params and a column count the query never mentions.

All three trace to one gap: nothing checks that both relations have fully-defined, named columns before delegating to _append_by_name. The docs note it "only works if the set of columns on both sides is fully defined," but the failure mode is silent-wrong or confusing rather than a clear message. The relation's ty already carries enough to detect a wildcard or unnamed field on either side; erroring there with something like append by:name requires both relations to have fully-defined, named columns would close it.

Retracting this approval. @max-sixty's review above documents three correctness bugs this happy-path read missed: an unnamed column silently dropped, by:name silently falling back to a position-union when schemas are unknown, and a confusing internal error when one side's columns are undefined. They all trace to nothing checking that both relations have fully-defined, named columns before delegating to _append_by_name. Happy to re-review once those are addressed.

[kgutwin]

Sounds fine, I added some more input validation to the append by:name code branch. Hopefully when the dialect-specific implementation is completed, these input requirements can be lifted (the SQL engine can easily handle wildcards and unnamed columns, since it is fully aware of both halves of the union).

[prql-bot]

The new validation cleanly closes all three cases from the earlier feedback: unnamed columns (x + 1), wildcard inputs (from b), and the asymmetric one-defined-one-not case now all produce clear, span-anchored errors instead of silent-wrong or internal-leak output. Nice.

One small inconsistency in the missing-lineage branch — see inline.

codecov/patch went red after this approval — patch coverage is 82.56% (34/195 new lines uncovered), below the auto target. The feature's happy path (test_append_by_name) and error paths (append_by_name_wildcard / append_by_name_unnamed) are covered; the gap is concentrated in the new general wildcard-resolution paths — construct_wildcard_from_lineage in expr.rs (~60%) and the second-pass lookup in resolve_ident_wildcard in names.rs (~80%), whose defensive match arms aren't exercised, plus the leftover trace instrumentation the earlier review flagged for pruning. Not a hard merge gate (codecov isn't in check-ok-to-merge), but withdrawing the empty-body approval so it doesn't sit over the red check — the earlier review remains the active verdict.