Exercise 1: Why the Breadcrumb CTE Walks Up, Not Down — Possible Solution
====================================================================

WHY THIS CAPSTONE'S RECURSION WALKS UPWARD
------------------------------
Per this chapter, "the breadcrumb recursive CTE... walks in the
opposite direction from postgres1-5's own employee-hierarchy example."
postgres1-5's employee hierarchy started from a single manager and
found every employee BELOW them at any depth — the natural direction
for "who reports to this person, directly or indirectly." This
capstone's breadcrumb needs the opposite: starting from ONE specific
category (e.g. "Laptops"), it needs to find every ancestor ABOVE it,
all the way to the root, to build a full display path like "Electronics
> Computers > Laptops." The real-world question being answered
("what is this category's full path from the top") is naturally an
upward question, not a downward one — a product's category doesn't
have a single fixed set of "children" that matter here, it has a
single, specific chain of ancestors.

WHAT MAKES THIS CHAPTER'S ANCHOR/RECURSIVE TERMS WALK UPWARD
------------------------------
Per this chapter's own query:

  WITH RECURSIVE breadcrumb AS (
    SELECT id, name, parent_id, name::TEXT AS path
    FROM categories
    WHERE id = 15

    UNION ALL

    SELECT c.id, c.name, c.parent_id, c.name || ' > ' || breadcrumb.path
    FROM categories c
    JOIN breadcrumb ON c.id = breadcrumb.parent_id
  )

The recursive term's JOIN condition is "c.id = breadcrumb.parent_id"
— it looks for the row whose id MATCHES the previous row's OWN
parent_id, which is precisely what walks toward the ROOT (each step
finds the current row's parent, not its children).

WHAT WOULD NEED TO CHANGE TO REVERSE THE DIRECTION
------------------------------
To walk downward instead (postgres1-5's own direction), the join
condition would need to be reversed to "c.parent_id = breadcrumb.id"
— looking for rows whose OWN parent_id matches the PREVIOUS row's id,
which finds children rather than the parent. This is exactly the join
condition postgres1-5's own employee example used ("e.manager_id =
org_chart.id"): finding every row whose manager_id points BACK to an
already-found row, which is the downward, "find my reports" direction.

WHY THIS WORKS AS AN ANSWER
------------------------------
It explains the different real-world question each direction answers
(ancestors vs. descendants), and identifies the precise, single
structural change (which side of the equality the previous row's id
appears on) that determines which direction the recursion walks.