From 2c7c948ac7d96c2aa977c2b1946898554e550906 Mon Sep 17 00:00:00 2001
From: Lodewijk <32471480+lgelauff@users.noreply.github.com>
Date: Thu, 4 Jun 2026 13:35:20 +0200
Subject: [PATCH] chore(db): remove never-implemented 2013 org/permissions
 table sketches
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

000000_initial.sql carried commented-out CREATE TABLE stubs for orgs, oadmins,
omemberships, org_member_metadata_types, and permissions. Blame traces them to 2013
(a01dc71c / 0341bf95) — early design sketches, never implemented: bare stub columns and
unresolved design notes (e.g. permissions has `--rwx?`, `--admin bool`). The org concept
that shipped is modeled on users (conversations.org_id -> users.uid, users.is_owner), not
these tables, so they were never needed.

Comment-only removal — no schema change (verified: 000000 still loads clean). They show
up as phantom tables to anyone grepping the file for CREATE TABLE.

Refs #2554
---
 server/postgres/migrations/000000_initial.sql | 29 -------------------
 1 file changed, 29 deletions(-)

diff --git a/server/postgres/migrations/000000_initial.sql b/server/postgres/migrations/000000_initial.sql
index 58415bf386..023773ef20 100644
--- a/server/postgres/migrations/000000_initial.sql
+++ b/server/postgres/migrations/000000_initial.sql
@@ -135,29 +135,6 @@ CREATE INDEX apikeysndvweifu_uid_idx ON apikeysndvweifu USING btree (uid);
 CREATE INDEX apikeysndvweifu_apikey_idx ON apikeysndvweifu USING btree (apikey);
 
 
-
-
-
-
---CREATE TABLE orgs (
-    --oid SERIAL,
-    --oname VARCHAR(999)
---);
-
---CREATE TABLE oadmins (
-    --uid REFERENCES users(uid),
-    --oid REFERENCES orgs(oid),
-    --UNIQUE (uid, oid)
---);
-
---CREATE TABLE omemberships(
-    --oid REFERENCES orgs(oid),
-    --uid REFERENCES users(uid),
-    --UNIQUE (uid, oid)
---);
-
---CREATE TABLE org_member_metadata_types (
-
 CREATE TABLE courses(
     course_id SERIAL,
     topic VARCHAR(1000),
@@ -502,12 +479,6 @@ CREATE TABLE suzinvites (
 CREATE INDEX suzinvites_owner_zid_idx ON suzinvites USING btree (owner, zid);
 
 
---CREATE TABLE permissions(
-    --uid INTEGER NOT NULL REFERENCES users(uid),
-    --zid INTEGER NOT NULL REFERENCES conversations(zid),
-    --rwx?
-    --admin bool
---);
 
 
  -- can't rely on SEQUENCEs since they may have gaps.. or maybe we can live with that? maybe we use a trigger incrementer like on the participants table? that would mean locking on a per conv basis, maybe ok for starters