Exercise 2: ALTER TABLE Limitations, the Standard Workaround, and DROP COLUMN's Real Improvement — Possible Solution
====================================================================

SQLITE'S HISTORICAL ALTER TABLE LIMITATIONS
------------------------------
Per this chapter, "for a long time, [SQLite's ALTER TABLE] could only
rename a table, add a column, or rename a column — it could not drop
a column, change a column's type, or add/remove constraints
directly." Compared to MySQL/Postgres, where ALTER TABLE can perform
a much wider range of schema modifications directly, historical
SQLite's own ALTER TABLE supported only three specific operations,
leaving anything else (removing a column, changing a column's type,
modifying constraints) unsupported through that statement.

THE STANDARD WORKAROUND PATTERN
------------------------------
Per this chapter, "for anything still beyond what ALTER TABLE
supports, the classic, genuinely accepted SQLite idiom — not a hack —
is: create a new table with the desired schema, copy the data over,
drop the old table, and rename the new one into place." Concretely,
this means: (1) create a brand-new table already having the final,
desired schema; (2) copy every row of data from the old table into the
new one (typically via an INSERT ... SELECT); (3) drop the old table
entirely; (4) rename the new table to take over the old table's own
original name. This chapter explicitly frames this as a genuinely
accepted, documented SQLite pattern, not an improvised workaround —
worth noting since it can look unusual to someone expecting a single
ALTER TABLE statement to handle every kind of schema change directly.

WHY DROP COLUMN (SQLITE 3.35, 2021) IS A GENUINE, RECENT IMPROVEMENT
------------------------------
Per this chapter, "SQLite 3.35 (2021) added DROP COLUMN support — a
real, recent improvement, worth naming honestly, echoing sqlite1-3's
own STRICT-tables-as-a-recent-fix pattern." This directly narrows the
gap between SQLite's own ALTER TABLE and MySQL/Postgres's more
complete versions — for the specific, common case of removing a
column, the four-step create/copy/drop/rename workaround is no longer
necessary; a genuine, direct ALTER TABLE ... DROP COLUMN statement now
works. This mirrors the honest pattern this course established with
STRICT tables in sqlite1-3 (SQLite 3.37): the course consistently
credits real, dated, ongoing improvements to SQLite rather than
treating its own historical limitations as permanently fixed facts.

WHY THIS WORKS AS AN ANSWER
------------------------------
It states the specific historical ALTER TABLE limitations using the
chapter's own wording, walks through the four concrete steps of the
standard workaround pattern, and explains specifically why crediting
the 2021 DROP COLUMN addition matters — connecting it explicitly to
the same honest, dated-improvement pattern the course already used for
STRICT tables in sqlite1-3.