Problem
stash init and stash schema build introspect the database to suggest which columns to encrypt. The introspection query filters to c.table_schema = 'public':
https://github.com/cipherstash/stack/blob/main/packages/cli/src/commands/init/lib/introspect.ts (introspectDatabase, the WHERE clause)
This is a sensible default for the common case — it shields users from system tables (pg_catalog.*, information_schema.*) and Supabase-managed schemas (auth.*, storage.*, vault.*, extensions.*) which should never be encrypted.
But it's wrong for users who put their application tables in a non-public schema:
- Per-tenant schemas (
tenant_a.users, tenant_b.users, ...).
- Domain-scoped schemas (
app.*, billing.*, analytics.*).
- Multi-app monorepos sharing one database with one schema per app.
For these users stash init reports "No tables found in the public schema" and falls back to the placeholder client, which is misleading — there are tables, they just live in a schema we're not looking at.
Possible directions
- Detect non-empty non-system schemas and prompt — list user-created schemas (i.e. excluding
pg_*, information_schema, and the Supabase-managed set) and let the user pick which ones to scan. Default to public if it's the only one that's populated.
- Heuristic main-schema detection — if
public is empty but exactly one other user schema has tables, scan that one with a one-line "Reading schema app" message.
--schema flag for power users who already know.
(1) is probably the right answer for the interactive flow; (3) is cheap to add alongside.
Out of scope of this issue
The fix for #396 (column-picker UX) keeps the public-only behaviour unchanged. This is a follow-up for the schema-scope question.
Problem
stash initandstash schema buildintrospect the database to suggest which columns to encrypt. The introspection query filters toc.table_schema = 'public':https://github.com/cipherstash/stack/blob/main/packages/cli/src/commands/init/lib/introspect.ts (introspectDatabase, the WHERE clause)
This is a sensible default for the common case — it shields users from system tables (
pg_catalog.*,information_schema.*) and Supabase-managed schemas (auth.*,storage.*,vault.*,extensions.*) which should never be encrypted.But it's wrong for users who put their application tables in a non-public schema:
tenant_a.users,tenant_b.users, ...).app.*,billing.*,analytics.*).For these users
stash initreports "No tables found in the public schema" and falls back to the placeholder client, which is misleading — there are tables, they just live in a schema we're not looking at.Possible directions
pg_*,information_schema, and the Supabase-managed set) and let the user pick which ones to scan. Default topublicif it's the only one that's populated.publicis empty but exactly one other user schema has tables, scan that one with a one-line "Reading schemaapp" message.--schemaflag for power users who already know.(1) is probably the right answer for the interactive flow; (3) is cheap to add alongside.
Out of scope of this issue
The fix for #396 (column-picker UX) keeps the public-only behaviour unchanged. This is a follow-up for the schema-scope question.