Exercise 1: Multi-Language Procedural Extensibility as the Real Difference — Possible Solution
====================================================================

WHY THIS ISN'T A "MYSQL CAN'T DO THIS" GAP
------------------------------
Per this chapter, "mysql3-8 already covered MySQL's own stored
procedures, and MySQL's procedural dialect genuinely does support
variables, loops, and conditionals — this isn't a 'MySQL can't do
this' chapter." Unlike the recursive CTE material in postgres1-5,
where MySQL genuinely had no equivalent capability in pure SQL before
8.0, MySQL's own stored procedure language is a real, working
procedural dialect — it can write the same kinds of logic PL/pgSQL
can, just using different syntax.

WHAT THE GENUINE ARCHITECTURAL DIFFERENCE ACTUALLY IS
------------------------------
Per this chapter, "the genuine architectural difference from MySQL
isn't procedural capability itself; it's that Postgres supports
multiple pluggable procedural languages for writing functions —
PL/pgSQL is the default and most common, but PL/Python, PL/Perl, and
PL/Tcl are also available as real, first-class options. MySQL has
only its own single built-in procedural SQL dialect, with no
comparable multi-language extensibility."

WHY THIS MATTERS PRACTICALLY
------------------------------
In Postgres, a developer already comfortable writing Python could
write a database function using PL/Python instead of learning
PL/pgSQL's own dialect from scratch, for tasks where Python's own
richer standard library or familiar syntax genuinely helps (complex
string processing, certain algorithms). MySQL offers no equivalent
choice — every stored routine has to be written in MySQL's own single
procedural SQL dialect, regardless of what language the surrounding
application is written in or what a given task might be easier to
express in.

WHY THIS IS THE PRECISE DISTINCTION TO DRAW
------------------------------
The real gap isn't "can Postgres do procedural logic and MySQL
can't" — both clearly can. The real gap is architectural: Postgres's
procedural-language layer is itself pluggable and extensible to
multiple languages, while MySQL's is a single, fixed dialect with no
comparable extension mechanism.

WHY THIS WORKS AS AN ANSWER
------------------------------
It explicitly states why this ISN'T a capability gap (both engines
have real procedural languages), using the chapter's own framing, and
then correctly identifies the actual difference (pluggable
multi-language architecture vs. one fixed dialect) rather than
misrepresenting MySQL as lacking procedural support entirely.