You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: README.md
+38-9Lines changed: 38 additions & 9 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -2,35 +2,46 @@
2
2
3
3
pgdiff compares the schema between two PostgreSQL 9 databases and generates alter statements to be *manually* run against the second database to make them match. The provided pgdiff.sh script helps automate the process.
4
4
5
-
pgdiff is transparent in what it does, so it never modifies a database directly. You alone are responsible for verifying the generated SQL *before* running it against your database, so you can have confidence that pgdiff is safe to try and see what SQL gets generated.
5
+
pgdiff is transparent in what it does, so it never modifies a database directly. You alone are responsible for verifying the generated SQL before running it against your database. Go ahead and see what SQL gets generated.
6
+
7
+
pgdiff is written to be easy to expand and improve the accuracy of the diff.
6
8
7
-
pgdiff is written to be easy to improve the accuracy of the diff. If you find something that seems wrong and you want me to look at it, please send me two schema-only database dumps that I can test with (Use the --schema-only option with pg\_dump)
(where options are defined below and <schemaType> can be: ROLE, SEQUENCE, TABLE, COLUMN, INDEX, FUNCTION, VIEW, FOREIGN\_KEY, OWNER, GRANT\_RELATIONSHIP, GRANT\_ATTRIBUTE, TRIGGER)
18
18
19
-
I've found that there is an ideal order for running the different schema types. For example, you'll always want to add new tables before you add new columns. This is the order that has worked for me, however "your mileage may vary".
19
+
I've found that there is an ideal order for running the different schema types. This order should minimize the problems you encounter. For example, you'll always want to add new tables before you add new columns. This is the order that has worked for me, however "your mileage may vary".
20
20
21
21
1. FUNCTION
22
22
1. ROLE
23
23
1. SEQUENCE
24
24
1. TABLE
25
+
1. COLUMN
25
26
1. VIEW
26
27
1. OWNER
27
-
1. COLUMN
28
28
1. INDEX
29
29
1. FOREIGN\_KEY
30
30
1. GRANT\_RELATIONSHIP
31
31
1. GRANT\_ATTRIBUTE
32
32
1. TRIGGER
33
33
34
+
35
+
### example
36
+
I have found it helpful to take ```--schema-only``` dumps of the databases in question, load them into a local postgres, then do my sql generation and testing there before running the SQL against a more official database. Your local postgres instance will need the correct users/roles populated because db dumps don't copy that information.
0 commit comments