Repository navigation
refactor: add schema snapshot - #66
Conversation
| -- | ||
| -- PostgreSQL database dump | ||
| -- | ||
|
|
||
| -- Dumped from database version 17.0 | ||
| -- Dumped by pg_dump version 17.0 | ||
|
|
||
| SET statement_timeout = 0; | ||
| SET lock_timeout = 0; | ||
| SET idle_in_transaction_session_timeout = 0; | ||
| SET transaction_timeout = 0; | ||
| SET client_encoding = 'UTF8'; | ||
| SET standard_conforming_strings = on; | ||
| SELECT pg_catalog.set_config('search_path', '', false); | ||
| SET check_function_bodies = false; | ||
| SET xmloption = content; | ||
| SET client_min_messages = warning; | ||
| SET row_security = off; |
There was a problem hiding this comment.
For better readability I think we should remove the unnecessary SETtings and comments.
There was a problem hiding this comment.
Unfortunately pg_dump doesn't have options for this. Changed the script to output to stdout and then do some piped greg -v filtering. Its not the prettiest but it works.
4ad1597 to
ddec27e
Compare
|
@AndrewJackson2020 can we add similar checks in other extensions as well if not present. |
This is being added with the below PR for pg_net. Not sure where else this would be useful on the rust side. Pg_Graphql? edit: looking at pg_graphql and jsonschema, neither of those extensions seem to have sql migration scripts. Happy to add this functionality to any other repo though, just let me know. |
194e001 to
41400b8
Compare
I think only c extensions for now. Rust extensions package SQL a little differently so can leave them alone. |
41400b8 to
9ec9704
Compare
50c245a to
6900568
Compare
6900568 to
e3f4c6b
Compare
|
Merged #75. This PR should be good to go now. |
We have moved on from maintaining multiple code path for new installs and migrations in SQL scripts which is nice and less error prone. But what we lose is the ability to diff the extension at a given point in time.
This PR adds a script and CI job that essentially snapshots the state of the extension and records it as text. This is useful because as we saw in pg_net in the past sometimes the incremental migration leads to a different outcome then was expected. For example one of the drifts that occurred in pg_net was dropping a primary key does not drop a null constraint automatically. With a snapshot we maintain the full state in addition to the incremental migration steps.