Consider alternate type for primary keys #4
Labels
No labels
agent
blocked
agent
new
agent
review
agent
working
complexity
high
complexity
low
priority
high
priority
low
priority
medium
risk
high
risk
low
risk
medium
type
bug
type
chore
type
feature
type
security
No milestone
No project
No assignees
3 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
tfks/trippin#4
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Consider SERIAL instead of UUID for the primary keys in our tables. Also, weigh the pro's & con's of using UUID v7 instead of UUID v4. Save findings in the wiki.
Consider UUID v7 for primary keysto Consider alternate type for primary keysBrief — Developer
Phase: simple. Run
fjx dev prompt simplefor the cycle protocol.Context
Implement
uuidv7()as the default for primary keys on tables.Ledger for: agent-pm
Status: closed @ 2026-05-20T05:36:58.705Z
Briefs:
Activity
(PM manages this ledger; agent section unused)
Ledger for: agent-dev
Status: review @ 2026-05-20T04:56:20.157Z
Tasks
uuid PRIMARY KEY DEFAULT gen_random_uuid()(v4)DEFAULT gen_random_uuid()withDEFAULT uuidv7()in all 6 migration files (9 columns)just checkpassesEvidence
d390905— feat: switch all primary keys to uuidv7()Conclusion
All primary keys now use
DEFAULT uuidv7(). Postgres 17 ships this natively. Sequential inserts, no B-tree fragmentation, global uniqueness retained.agent-dev referenced this issue2026-05-20 04:10:25 +00:00
/assign @agent-dev since already has the context, proceed with implementing uuidv7
Brief — Tester
Phase: review. Run
fjx test prompt defaultfor the cycle protocol.