Exercise 1: Array Columns vs. Comma-Separated Strings, and the Overuse Caution — Possible Solution
====================================================================

WHAT A POSTGRES ARRAY COLUMN OFFERS
------------------------------
Per this chapter, "MySQL has no native array type — the standard
workaround is either a proper join table, or a comma-separated string
column, a well-known anti-pattern. Postgres arrays give a genuine,
indexable, queryable alternative to the string-column workaround,
using containment operators (@>, <@) and unnest()." A comma-separated
string column (e.g. "databases,postgres,sql") has to be parsed and
searched with fragile, imprecise string-matching (a LIKE '%postgres%'
query, for instance, which could also false-match a tag like
"postgresql_admin"). A Postgres array column, by contrast, stores
each element as a genuine, independently-typed value, can be queried
precisely with the @> containment operator (per this chapter's own
example: WHERE tags @> ARRAY['postgres']), and can be expanded into
individual rows cleanly using unnest() — none of which the
comma-separated string approach can do reliably.

THE OVERUSE CAUTION FROM THE WARN-BOX
------------------------------
Per this chapter's own warn-box, "this chapter's own type richness can
tempt a design toward reaching for an array... when a proper join
table or lookup table would actually serve the data better long-term
— the same 'when to choose each' judgment postgres1-1 applied at the
engine level applies again here, at the level of individual column
design." The warn-box also states plainly that "an array column can
violate normalization the same way a comma-separated string can; it's
a convenience with better tooling, not a normalization loophole."

WHY BOTH POINTS MATTER TOGETHER
------------------------------
An array column is a genuine technical improvement over a
comma-separated string for the SAME use case — but it doesn't
automatically justify choosing that use case over proper
normalization in the first place. If tags needed their own metadata
(a description, a creation date, a many-to-many relationship to
multiple post types), a real join table would still be the better
design, array or no array. The array type improves how a
denormalized choice is implemented; it doesn't remove the underlying
design question of whether denormalizing was the right choice at all.

WHY THIS WORKS AS AN ANSWER
------------------------------
It explains the concrete querying advantage using the chapter's own
example syntax, and states the warn-box's own caution precisely
rather than treating array columns as an unqualified improvement.