materialize
materialize copied to clipboard
MaterializeInc
[Epic] sql: formalize output of `SHOW` commands
Work items
- [x] #14639
- [x] #14642
- [x] #14643
- [x] #14644
- [x] #14646
- [x] #12700
- [ ] #14647
- [x] #14648
- [x] #14547
- [ ] #14649
- [x] #14876
- [x] #14727
Background and rationale
From @benesch in #11190:
Platform is a good opportunity to revisit the
SHOWcommands en masse and tailor them to our liking, rather than the Franken-MySQL we've got right now.
The SHOW commands are a MySQL-ism that CockroachDB borrowed, despite largely providing a PG-alike API, and we have largely followed suit. However, as Materialize develops we have extended our SHOW commands to provide access to dimensions specific to Materialize, e.g. SINKS, IN CLUSTER.
Before we ship platform, we'd like to firm up the output of these commands to ensure some kind of consistent reasoning about their output (at the very least--thinking about their input might be good, as well) so we can make rote decisions about any extensions we need to make in the future.
Tagging this as A-sql because the show commands are manifest in SQL planning code, but thinking about the structure of what the output should be is likely a more cross-cutting concern because it involves an expression of how each class of object wants to present itself. The SQL team likely wants to get e.g. sources and sink's feedback about how sources and sinks want to handle SHOW SOURCES etc.
Work items by statement
SHOW DATABASESis in good shape.SHOW SCHEMASis in good shape, modulo #14642.SHOW CONNECTIONS: #14643.SHOW TABLESis in good shape. Columns are described bySHOW COLUMNS.SHOW VIEWSsame asSHOW TABLES.SHOW MATERIALIZED VIEWS: #14648.SHOW OBJECTS: #14644.SHOW SOURCES: #14647.SHOW SINKSsame asSHOW SOURCES.SHOW TYPESis in good shape, modulo #14642.SHOW INDEXES: #12700.SHOW COLUMNS: #14646SHOW CLUSTERSis in good shape.SHOW CLUSTER REPLICASneeds information about size and availability zone.SHOW SECRETSis in good shape.
One request here: all SHOW commands are sql syntax sugar for a regular SELECT over a system table. This allows folks to use subqueries and otherwise modify these results with general SQL.
Editor's note: this has been filed as #14547.
We should absolutely do this, but I'm not totally convinced that it's a platform blocker. @sploiselle or @benesch - would you mind giving more context on the priority here?
@JLDLaughlin The idea behind labeling this as a platform blocker was codifying the shape of these queries to prevent easy-to-avoid breaking changes, i.e. the release of platform should have a stable API, i.e. provides a contract with users that they can build tooling on top of MZ without regular breakage.
@chaas @ggnall I broke this issue down into bite-sized work items, all linked in the description. I'm not sure what protocol is for prioritization and tracking—should each of these issues be marked for triage separately? Should each get added to the SQL project board? Or should we just track this meta issue? I figured I'd leave it to you two to sort out, if that works!
Wow thanks @benesch ! Really appreciate you taking the time to think this out. Graham is OOO the next two weeks, so I'll be handling solo. For prioritization and high-level tracking the epic level is fine. Once implementation begins, we can track the tickets' progress via the board to ensure multiple people don't implement the same change if we have more than one person working on it.
Unsure whether this is something legit to expose, but AFAICT we don't make source or replica sizes available anywhere. How would one check the current size of a source, or the size of each replica in a cluster? For sources, this information is probably accessible through SHOW CREATE SOURCE, though that's not the most ergonomic way to check for size.
Edit: Just noticed that this is already laid out for SHOW CLUSTER REPLICAS!
This is done! The only thing outstanding is #14649, which we're not planning to tackle now. All the commands are documented on their own pages currently.