Skip to content

Fix named parameter syntax in GIQL operators to use := and => instead of = #63

Description

@conradbzura

Description

All GIQL operators that accept keyword arguments (CLUSTER, MERGE, DISTANCE, NEAREST) treat the equality operator = as a parameter assignment operator in their from_arg_list methods. In standard SQL, = inside a function call is an equality comparison that returns a boolean — not parameter binding. The canonical named parameter syntaxes are := (PostgreSQL) and => (SQL standard).

COVERAGE already handles this correctly (fixed in #62), accepting only exp.PropertyEQ (:=) and exp.Kwarg (=>). The remaining four operators need the same fix.

Expected behavior

Operators accept only := (PostgreSQL-style) and => (SQL-standard) for named parameter binding. CLUSTER(interval, stranded := true) and CLUSTER(interval, stranded => true) bind the stranded parameter. CLUSTER(interval, stranded = true) is treated as a positional argument containing an equality comparison, consistent with standard SQL semantics.

Root cause

Each operator's from_arg_list classmethod checks isinstance(arg, exp.EQ) to detect named parameters. SQLGlot parses foo(x=1) as an EQ (equality comparison) node, and from_arg_list reinterprets that comparison as a named parameter binding. This works by accident but is semantically wrong.

The four affected classes are GIQLCluster, GIQLMerge, GIQLDistance, and GIQLNearest in src/giql/expressions.py. Documentation files referencing the = syntax (docs/dialect/, docs/recipes/, docs/quickstart.rst, docs/transpilation/performance.rst) and existing tests using = for named params also need updating.

Metadata

Metadata

Assignees

Labels

bugSomething isn't working

Type

No type
No fields configured for issues without a type.

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions