Add notes for 2018-06-24

content/posts/2018-06.md

@@ -227,4 +227,20 @@ UPDATE 1
 - I uploaded the twenty-four reports to the IWMI Reports collection: https://cgspace.cgiar.org/handle/10568/36188
 - I uploaded the seventy-six book chapters to the IWMI Book Chapters collection: https://cgspace.cgiar.org/handle/10568/36178
 
+## 2018-06-24
+
+- I was restoring a PostgreSQL dump on my test machine and found a way to restore the CGSpace dump as the `postgres` user, but have the owner of the schema be the `dspacetest` user:
+
+```
+$ dropdb -h localhost -U postgres dspacetest
+$ createdb -h localhost -U postgres -O dspacetest --encoding=UNICODE dspacetest
+$ psql -h localhost -U postgres dspacetest -c 'alter user dspacetest superuser;'
+$ pg_restore -h localhost -U postgres -d dspacetest -O --role=dspacetest -W -h localhost /tmp/cgspace_2018-06-24.backup
+$ psql -h localhost -U postgres dspacetest -c 'alter user dspacetest nosuperuser;'
+```
+
+- The `-O` option to `pg_restore` makes the import process ignore ownership specified in the dump itself, and instead makes the schema owned by the user doing the restore
+- I always prefer to use the `postgres` user locally because it's just easier than remembering the `dspacetest` user's password, but then I couldn't figure out why the resulting schema was owned by `postgres`
+- So with this you connect as the `postgres` superuser and then switch roles to `dspacetest` (also, make sure this user has `superuser` privileges before the restore)
+
 <!-- vim: set sw=2 ts=2: -->