Exercise 1: What CREATE EXTENSION Does, and Why It's More Than a Naming Difference From MySQL's Plugins — Possible Solution
====================================================================

WHAT CREATE EXTENSION ACTUALLY DOES
------------------------------
Per this chapter, "a Postgres extension is a packaged, installable
addition to a running instance — new types, functions, operators, and
even index access methods, bundled and installed with a single CREATE
EXTENSION extension_name;, rather than requiring a Postgres recompile
or manually loading a scattering of separate SQL and library files."
Running CREATE EXTENSION registers a coherent, versioned bundle of
new SQL-level capability into the current database in one step — new
types that can be used in CREATE TABLE, new functions that can be
called in ordinary queries, new operators, and even, in PostGIS's own
case, entirely new index access methods.

WHY THIS IS A GENUINE ARCHITECTURAL DIFFERENCE FROM MYSQL'S PLUGINS
------------------------------
Per this chapter, "MySQL has its own plugin mechanism, a comparable
low-level C-plugin system — but nothing with quite the same reach or
the 'run one command, immediately gain new SQL-level types, operators,
and functions' workflow." The key distinction is what a plugin/
extension actually EXPOSES once installed. MySQL's plugin system
operates at a lower, more infrastructural level (storage engines,
authentication mechanisms) without the same broad, direct path to
adding genuinely new SQL-level TYPES and OPERATORS usable directly in
ordinary queries the way Postgres extensions routinely do. Postgres's
own extension mechanism was specifically designed as a first-class way
to extend the SQL surface itself, which is exactly why capabilities
as large and mature as PostGIS or TimescaleDB (per this chapter's own
"Broader Ecosystem" section) can be built entirely as extensions
rather than needing to be forks of Postgres itself or separate
database systems.

WHY THIS ISN'T JUST A LABELING DIFFERENCE
------------------------------
If this were purely a naming difference, PostGIS-scale functionality
(hundreds of new spatial functions, new geometry/geography types, new
spatial index support) would be equally achievable as a MySQL plugin.
Per this chapter's own framing, this genuinely isn't the case — the
depth and SQL-level reach of Postgres's extension mechanism is a real,
structural reason its ecosystem includes production-grade systems like
PostGIS and TimescaleDB built directly as extensions, a pattern MySQL's
own plugin ecosystem doesn't have a comparable equivalent for.

WHY THIS WORKS AS AN ANSWER
------------------------------
It explains the mechanism concretely using the chapter's own wording,
and specifically identifies WHAT capability gap (SQL-level type/
operator/function reach) makes this a genuine architectural difference
rather than a difference in terminology alone.