The same calls as pgvector SQL
It only prints. A real adapter would send these statements with parameters through a PostgreSQL driver (Topic 5.10 shows where).
AskDocs version 5 puts a VectorStore interface between the product and its vectors: upsert, delete and search with a filter. An in-memory version runs here, and a second version shows the pgvector SQL the same calls map to.
Change the code and press Run (Ctrl+Enter). Predict what will happen first, then break it on purpose and read what changes. Your edits are saved and match the lesson page.
Ready for more? This phase has 5 hands-on exercises with automatic checks.
Practice questions
Write the code in the editor, run it, then open the model answer to compare.
Add count() to the in-memory store and delete_where(where) that removes every point whose payload matches the filter. Print the count before and after delete_where({"version": "2023"}) on a store with three points.
Write get(point_id) that returns (vector, payload) or None, and print None for a missing id. Why does a real adapter need this method for re-ingestion (Topic 4.7)?
Explain it without notes
What does the VectorStore interface contain, and what does each method return?
How does the version filter change the refund answer, and why not simply delete the old document?
How does the SQL version map search(vector, 3, {version: '2025'})?
Why are values passed as parameters but column names built into the text?
Expected output
INSERT INTO chunks (id, version, embedding) VALUES ($1, $2, $3) ON CONFLICT (id) DO UPDATE SET version = EXCLUDED.version, embedding = EXCLUDED.embedding;
params: D3 | 2025 | [0.00,0.50,0.87,0.00]
DELETE FROM chunks WHERE id = $1;
params: D1-old
SELECT id, 1 - (embedding <=> $1) AS score FROM chunks WHERE version = $2 ORDER BY embedding <=> $1 LIMIT $3;
params: [0.00,0.00,1.00,0.00] | 2025 | 3
SELECT id, 1 - (embedding <=> $1) AS score FROM chunks ORDER BY embedding <=> $1 LIMIT $2;
params: [1.00,0.00,0.00,0.00] | 5