SEARCH rejects a quoted collection name while accepting a quoted column argument #212

Version / build tested against

origin/main @ 7bd4d24

Deployment mode

Origin — single node (local)

Engine(s) involved

Vector

Summary

SEARCH "collection" USING VECTOR(...) fails in the parser — the collection name in a SEARCH statement must be a bare identifier. A double-quoted column argument inside VECTOR(...) is accepted, so quoting is handled inconsistently within the same statement. A collection whose name requires quoting (mixed case, or a name colliding with a keyword) therefore cannot be searched at all.

Steps to reproduce

DROP COLLECTION IF EXISTS vec_probe;
CREATE COLLECTION vec_probe;
CREATE VECTOR INDEX idx_vec_probe ON vec_probe (embedding) METRIC COSINE DIM 3;
INSERT INTO vec_probe (id, title, embedding) VALUES
  ('a1','one',ARRAY[0.1,0.2,0.3]), ('a2','two',ARRAY[0.4,0.5,0.6]);

SEARCH vec_probe USING VECTOR(embedding, ARRAY[0.1,0.2,0.3], 2);
-- 2 rows      <- bare names: correct

SEARCH vec_probe USING VECTOR("embedding", ARRAY[0.1,0.2,0.3], 2);
-- 2 rows      <- quoted column: accepted

SEARCH "vec_probe" USING VECTOR(embedding, ARRAY[0.1,0.2,0.3], 2);
-- ERROR:  parse error: sql parser error: Expected: an SQL statement, found: SEARCH at Line: 1, Column: 1

Expected behavior

A double-quoted identifier is accepted wherever a bare identifier is, including the collection position of SEARCH. Consistent with the quoted column argument already being accepted.

Actual behavior

The statement is rejected at column 1 — the dispatcher does not recognize the statement as a SEARCH at all once the collection name is quoted, so the error text points at SEARCH rather than at the quoting. Collections whose names need quoting are unreachable through vector search.

What actually happened? (check all that are true)

• Acknowledged/committed data was lost, corrupted, or silently wrong
• The server crashed, hung, or failed to start
• A security or isolation boundary was crossed
• Core functionality is broken with no acceptable workaround
• A workaround exists (rewrite the query, avoid one path, etc.)

Proposed severity

SEV-3 — Medium: feature wrong, but operational and a workaround exists

Reproducibility

Always — every attempt

Last known-good version / commit (if a regression)

(blank — never worked)

Environment & logs

Linux x86_64, release build from source (nodedb 0.4.0, git commit: 7bd4d24b6). Single local node, fresh data directory. Client-visible parse error only.

Files (best guess): the DSL statement dispatcher matches on the raw token sequence before identifier unquoting, so a quoted collection name breaks the prefix match.

Before submitting

• I searched existing issues and this is not a duplicate.
• I reproduced this on a released tag or a current main build (not a stale local branch).
• This is not a security vulnerability (those go to a private advisory).