Exercise 3: Postgres's Reusable ENUM Type vs. MySQL's Column-Level ENUM — Possible Solution
====================================================================

POSTGRES'S ENUM
------------------------------
Per this chapter, "Postgres's CREATE TYPE mood AS ENUM ('sad', 'ok',
'happy') creates a genuine, named, reusable type — it shows up as its
own type in \d output, and any number of columns across any number of
tables can be declared using it, sharing one single validated
definition." A Postgres ENUM is a real type in the type system,
comparable to any built-in type, that multiple tables can reference.

MYSQL'S ENUM
------------------------------
Per this chapter, "MySQL's ENUM is a column-level attribute, not a
real named type — each column defines its own independent enum, even
if two columns want identical values, with no cross-table reuse and
no clean way to reference 'the same enum' elsewhere." In MySQL, each
column's ENUM('sad', 'ok', 'happy') definition is local to that one
column — a second column, even in the same table, that wants the
identical set of allowed values has to redefine that exact list all
over again, with no shared, single source of truth.

A CONCRETE CONSEQUENCE: ALTERING VALUES LATER
------------------------------
Per this chapter, "Postgres also allows adding a new value to an
existing enum type cleanly (ALTER TYPE mood ADD VALUE 'ecstatic'),
whereas altering a MySQL column-level ENUM's values typically means
an actual ALTER TABLE against the column definition itself." If a
new allowed value needs to be added later:

- In Postgres, a single ALTER TYPE mood ADD VALUE 'ecstatic' updates
  the type definition once, and every column across every table using
  that type immediately reflects the new allowed value — because they
  all reference the same shared type.
- In MySQL, since each column has its own independent, locally-defined
  ENUM list, adding a new value means running an ALTER TABLE against
  EVERY individual column that needs the new value, one at a time —
  and if the same values were duplicated across several columns (per
  MySQL's own lack of reuse), each of those columns has to be updated
  separately, with real risk of them drifting out of sync with each
  other over time.

WHY THIS WORKS AS AN ANSWER
------------------------------
It states the structural difference (a shared, referenced type vs. a
per-column local definition) using the chapter's own wording, and
traces that structural difference to a concrete, practical consequence
(how many places have to change, and the risk of drift) when the
allowed values need to be updated later.