Schema: the published-copy columns #7865

Task Summary

Part of #7828, the first of the series. Adds the columns a pinned public copy lives in, and nothing that reads them — the code that does arrives in the following tasks.

• Four columns on workflow (sql/updates/41.sql; 38–40 are taken upstream) — published_content is the pin itself, NULL while the workflow follows the author's latest; published_name and published_description freeze with it, because a title is as public as the graph; published_version_id points at the revision-history row the copy was pinned from.
• A CHECK constraint, published_content IS NULL OR is_public — a pin only means something while the workflow is public, and making that unrepresentable is cheaper than catching it in every path that could break it.
• A PGroonga index over the frozen columns, mirroring the existing one over the live content. Public search matches a pinned workflow against the copy on show, so that copy needs an index of its own; the expression has to match the query's verbatim or the planner cannot use it.
• No backfill. Every workflow that is public today has no pin, which is the following state, which is exactly what it does today: deploying this changes nothing anyone can see.
• One call-site change. jOOQ generates Workflow's constructor positionally, so four new columns widen it from 7 to 11 parameters and the copy-producing paths (clone, duplicate, restore-a-version) stop compiling. They move to a named newUnpublishedWorkflow helper built with setters, so a future column cannot silently shift a null into the wrong field.

Covered by PublishedCopySchemaSpec: the columns land NULL on a new workflow, a public workflow may carry a frozen copy, and a private one is refused by the database.

Task Type

• Other (schema change)

Task Type

• Refactor / Cleanup
• DevOps / Deployment / CI
• Testing / QA
• Documentation
• Performance
• Other