What planned means here
Intent, not a commitment. Everything below is unbuilt. There are no dates, no order of arrival, and no guarantee that any particular one of them ships. If you are choosing a tool, choose it on what it does today.
Planned
Four things, and each one is paired with what sloop does in its place today — because the useful question about an unbuilt feature is usually what do I do until then.
Planned
Writing and saving queries
Writing a query rather than building one, and keeping it under a name to run again.
Today
sloop query builds a read-only query from a screen of questions, and --sql runs one statement. Nothing is saved, and nothing either of them runs can write.
Reading a database →
Planned
DDL
Creating and altering tables from sloop.
Today
sloop db create makes a database and the role that owns it, then registers it. Inside a database, the only schema sloop writes is one a dump carried into a restore or a mirror — never one you described to it.
Databases and registries →
Planned
Editing rows in place
Changing a value in the results grid, and having that reach the database.
Today
The grid shows two hundred rows at a time and is read-only — enforced by the server, which has been told the transaction cannot write.
Reading a database →
Planned
A local interface
Something with a window, reading sloop's own PostgreSQL the way the CLI reads it.
Today
sloop server connection prints host, port, user and database, so psql, DataGrip or anything else can open that database today.
sloop's own PostgreSQL →
Not on it
A list of what is planned is only half of an honest one. Here is the thing people ask for most that is deliberately absent:
Copying between engines
PostgreSQL to MySQL has been worked through, measured against real servers rather than recalled, and it is on hold. It is not on this list, and there is no date on which it will be.
The reason is structural. sloop has no type model, because it has never needed one: every copy it performs is performed by the engines’ own client programs, and no value passes through sloop. Cross-engine, sloop becomes the thing moving the bytes, and every guarantee that is free today — exact row counts, a source that is only read, a failed copy that leaves nothing behind — has to be re-earned by hand.
So mirror, sync and restore all refuse across engines today, and each says why rather than pointing at a ticket.
copying between engines is not built: the type systems do not map cleanly, and a copy that quietly rounds or truncates is worse than one that refuses.
Mirror and sync shows that refusal happening, and says what to do instead.
What is not going to change
The other thing a roadmap should say. These are not on a list because they are not going anywhere, and anything above has to arrive without breaking them:
- The guarantee
- No HTTP client in the dependency graph, and no SSH client either. CI fails the build on the day one appears, so nothing on the list above can arrive by adding one.
- The exit codes
- Frozen at 1.0. Adding a code is a feature; changing what one means is a breaking release, and a test in the source asserts every number and says so.
- Never prompting without a terminal
- Anything added here has to hold that too. A screen of questions is only ever an alternative to a flag, never the only way to say something.
Security has the first of those as something you can check in thirty seconds rather than take on trust, and Automation has the second as the nine numbers a scheduler reads.
Asking for something
sloop is built from a list its owner keeps, informed by people who run these databases every day. If something you need is missing, the repository is where to say so — and a description of the problem is worth more than a description of the feature, because the refusals on this page exist where the obvious feature was the wrong answer to a real problem.