Exercise 2: Why a New Post Type Needs No New Database Table — Possible Solution
====================================================================

WHAT WORDPRESS FUNDAMENTALS 3 ESTABLISHED
------------------------------
Per this chapter's own opening, "WordPress Fundamentals 3 made a
promise: since Posts and Pages are really just two values of the same
underlying post_type column, nothing stops a developer from defining a
third." Posts and Pages were never stored in two separate tables to
begin with - they live in one shared table, with a single column
recording which type each specific row actually is.

WHAT register_post_type() ACTUALLY DOES, PER THIS CHAPTER
------------------------------
Per this chapter's own finding-box, "once this runs, portfolio becomes
a real, valid value for the very same post_type column already holding
post and page. A Portfolio Item isn't stored in some separate, new
system - it's an ordinary row in the exact same database table,
distinguished the same way Posts and Pages always have been."
register_post_type() doesn't create a new table, define new columns, or
alter the database schema in any way - it simply tells WordPress that
'portfolio' is now a recognized, valid value that can appear in that
existing column, along with everything WordPress needs to know to
handle rows carrying that value correctly (which admin screens to show,
which editor features to enable, whether it gets an archive page, and
so on).

WHY NO NEW TABLE IS NEEDED
------------------------------
Since the underlying storage mechanism (one shared table, one
type-identifying column) already exists and already works for Posts
and Pages, adding a third possible value to that same column requires
no new storage structure at all - it reuses the exact same mechanism
that was always capable of holding more than two distinct values, it
simply hadn't been asked to before. A new post type is a registration
of a new label/configuration, not a request for new storage.

WHY THIS IS THE DIRECT PAYOFF OF WORDPRESS FUNDAMENTALS 3'S OWN REVEAL
------------------------------
This is precisely why that earlier chapter's own technical detail (the
shared table, distinguished by one column) mattered enough to flag in
advance - understanding that Posts and Pages were never architecturally
special makes it immediately clear why a custom post type is cheap to
add: it's reusing infrastructure that was always general enough to
support it.

WHY THIS WORKS AS AN ANSWER
------------------------------
It restates the exact promise WordPress Fundamentals 3 made and this
chapter's own delivery on it, explains precisely what register_post_type()
does and doesn't do to the database, and connects the underlying
reasoning (shared table, shared mechanism) directly back to the earlier
chapter's own reveal rather than treating the two as unrelated facts.