sql: Rename `mz_internal` schema to `mz_unstable`

[jkosh44]

Feature request

After https://github.com/MaterializeInc/materialize/pull/22889 we have two schemas which are "non-stable", mz_unsafe and mz_internal.

• mz_unsafe - objects which cannot be called or referenced by users
• mz_internal - objects or functions which can be called and referenced by users, but can possibly change, so we don't allow them in VIEWS or MATERIALIZED VIEWS.

This issue is to track the work in renaming mz_internal to mz_unstable. Nothing about the objects in mz_internal are actually "internal" to Materialize, they're just unstable, as such we impose limitations to how they can be used. This was discussed in Slack

[benesch]

Oh beautiful, thank you for filing. Linking in my thoughts from Slack: https://materializeinc.slack.com/archives/C063H5S7NKE/p1701791151710269

[benesch]

@ParkMyCar points out on Slack that "unstable" and "unsafe" sound awfully similar.

An alternative for consideration: mz_preview and mz_unsafe.

[RobinClowers]

Are we planning to do anything to support this transition for customers? I'm thinking about various monitoring solutions customers have rigged up that target mz_internal. cc @teskje who is also thinking about this.

[benesch]

Summarizing the latest proposal from Slack:

• mz_introspection — schema for per-replica introspection relations
• mz_catalog — schema for stable catalog tables, views, and functions
• mz_catalog_unstable — schema for catalog tables, views, and functions that are not yet stable, but are intended to one day be stabilized
• mz_internal — schema for internal tables and functions that are not meant to be used by external users and are not on a path to stabilization

[teskje]

Are we planning to do anything to support this transition for customers? I'm thinking about various monitoring solutions customers have rigged up that target mz_internal.

We are not obliged to do this, since we explicitly spell out mz_internal relations to be unstable. That said, I've now talked myself into adding some automatic translation scheme like for the mz_introspection cluster rename, if it's not a huge amount of hassle. It should be possible to do this since relation names are unique on their own, so we can just search through the other schemas if we don't find something in mz_internal first.

In addition to being more convenient for our users, an automatic translation also makes the migration of our internal clients easier, which is nice.

[RobinClowers]

Awesome, if that works out, console could just wait until it was released to all customers, then rename everything, rather than version guarding it, which makes our lives much easier! If that doesn't end up working out for some reason, I have a plan for the version guard, but it's a fair amount of work.

[benesch]

You may already have this on your radar, @teskje, but we'll need to handle the automatic translation in at least two places: when mz_internal is on the search path, and when it's explicitly used in an object reference (mz_internal.mz_whatever).