Exercise 3: Why the Range-Overlap Exclusion Constraint Needs GiST, Not B-Tree — Possible Solution
====================================================================

THE CONNECTION THIS CHAPTER NAMES
------------------------------
Per this chapter, GiST "is the exact index structure powering
postgres1-3's own EXCLUDE USING gist range-overlap constraint." The
hotel-booking exclusion constraint from postgres1-3 — EXCLUDE USING
gist (room_id WITH =, stay WITH &&) — is only possible at all because
GiST exists as an index structure capable of supporting it.

WHY A B-TREE CAN'T SUPPORT THIS CONSTRAINT
------------------------------
A B-tree index is built around a strict, total ordering of single
values — it can efficiently answer "is this value equal to X" or "is
this value between X and Y," because those questions rely on a
value's position in a linear order. But "does this range OVERLAP that
range" (the && operator from postgres1-3) isn't a question about
ordering a single value at all — two ranges can overlap in ways that
have no simple linear-ordering relationship to each other (e.g. one
range could start before and end after another, or partially overlap
on either side). There's no way to sort ranges into a single line
such that "overlapping" ranges always end up adjacent to each other
in that ordering — which is exactly the kind of structural mismatch
that makes a B-tree the wrong tool here.

WHY GiST CAN SUPPORT IT
------------------------------
Per this chapter, GiST "supports a broader, extensible class of
queries than GIN — nearest-neighbor search, geometric and spatial
queries." GiST is specifically designed to be extensible to
non-linear, spatial-style comparison operators — overlap, containment,
distance — rather than being locked into a strict total ordering the
way B-tree is. A range-overlap check is conceptually similar to a
geometric/spatial "do these two shapes intersect" question, which is
exactly the category of query GiST's own extensible structure is
built to support. This is why Postgres's EXCLUDE constraint mechanism
requires an index type capable of evaluating the specific operator
being excluded on (here, &&) — and GiST is the index type that can
actually do that for range overlap.

WHY THIS WORKS AS AN ANSWER
------------------------------
It explains specifically why B-tree's own strict-ordering design
can't represent an overlap relationship, and connects GiST's own
stated flexibility (spatial/geometric-style queries) to why it's the
structure actually capable of enforcing the range-overlap exclusion
constraint from postgres1-3.