https://github.com/solidsnack/macaroon
Postgres introspection and macros
https://github.com/solidsnack/macaroon
Last synced: over 1 year ago
JSON representation
Postgres introspection and macros
- Host: GitHub
- URL: https://github.com/solidsnack/macaroon
- Owner: solidsnack
- Created: 2015-06-28T06:33:01.000Z (almost 11 years ago)
- Default Branch: master
- Last Pushed: 2023-01-01T06:41:48.000Z (over 3 years ago)
- Last Synced: 2025-03-05T17:08:16.758Z (over 1 year ago)
- Language: PLpgSQL
- Size: 23.4 KB
- Stars: 18
- Watchers: 3
- Forks: 3
- Open Issues: 1
-
Metadata Files:
- Readme: README.md
- Audit: audit.sql
Awesome Lists containing this project
README
Many tricky table configurations -- for example, logged tables and partitioned
tables -- would seem to be amenable to mechanical derivation. The SQL standard
provides for fairly rich introspection capabilities -- on par with any object
oriented language -- so it stands to reason that we should be able to use
metaprogramming to derive advanced table configurations mechanically.
The `meta` schema in `meta.sql` should be loaded before loading the others. To
load all the schemas together, run `\i macaroon.psql` at the `psql` prompt.
Creating Tables for Auditing & Versioning
-------------------------------------------
Imagine that your application has tables in the `app` namespace; and you'd like
to log past row versions and metadata about changes to the `state` and `events`
schemas, respectively. You can idempotently configure both audit and version
stracking by `SELECT`ing tables in the `app` namespace that are not already
tracked and passing them to the setup functions:
```sql
SELECT tab,
temporal.temporal(tab, 'state'),
audit.audit(tab, 'events')
FROM pg_tables,
LATERAL (SELECT (schemaname||'.'||tablename)::regclass AS tab)
AS casted_to_regclass
WHERE schemaname = 'app'
AND tab NOT IN (SELECT logged FROM temporal.logged
UNION
SELECT audited FROM audit.audited);
tab │ temporal │ audit
───────────────┼─────────────────┼──────────────────
app.user_info │ state.user_info │ events.user_info
app.telephone │ state.telephone │ events.telephone
app.cpu │ state.cpu │ events.cpu
... │ ... │ ...
```
Using The Auditing & Versioning Tables
--------------------------------------
The audit and temporal tables for each table that is tracked can be joined on
the `txid` column to see all the actions that took place during a particular
transaction.
A Note About Migrations
-----------------------
The audit tables are indifferent to migrations -- they do not store any row
data.
The temporal tables store `JSONB`, so they're also indifferent to migrations.