Updated uninstall script for M2

[wildtayne]

This PR updates the uninstall script to work with M2. I have changed to using the DROP OWNED BY ClassDB approach outlined here. We can discuss if this solution is sufficient in our next sync, if necessary.

This method should no longer forcefully drop user objects that depend on ClassDB objects.

Fixes #147 and #146

[wildtayne]

Closing until dir. reorg is done

[wildtayne]

Reopened and editing PR comment

[wildtayne]

I just pushed another commit that sets ClassDB.IDNameDomain's owner to ClassDB, while before it was owned by the superuser. This is necessary for DROP OWNED BY ClassDB to work, since many of the ClassDB functions depend on ClassDB.IDNameDomain.

When testing the uninstaller, I would recommend creating a new install of ClassDB from the scripts in this branch, as many missing assigns and grants have been added in dev. I ran into several problems running the uninstaller that were due to old functions that have since been removed from ClassDB, or incorrect function permissions that are now fixed.

[smurthys]

Nice changes @srrollo. Using DROP OWNED BY is a good idea. (I should have suggested this approach earlier, because function dropRole already uses DROP OWNED BY.)

I have the following thoughts on removeAllFromDB.sql:

• The file prologue should probably say that the script stops if drop fails at any point (due to not using DROP...CASCADE)
• L101: The only reason to have this line is if the ClassDB schema is somehow not owned by the ClassDB role (and thus the schema is not already dropped by L98). Perhaps a comment to that effect helps.
• I recommend moving L98 and L101 to immediately after L 84.
• Doesn't the comment on L90 in general also apply to code in L87-L88?

Also, thank you for adding ownership to ClassDB.IDNameDomain. I'd missed doing that.

[smurthys]

FY, I'll be away for 60-90 minutes. So, please feel free to merge this PR unless one of you discovers something major. I'll approve the PR in anticipation of there being no such problem.

[afig]

Thanks for working on the uninstall script @srrollo. I tried running it on a clean M2 install, but received the following error (showing full output since it may be helpful in determining where the script fails):

classdbtest=# \i removeAllFromDB.sql
START TRANSACTION
SET
DO
DO
DO
DROP OWNED
DROP OWNED
DROP OWNED
DROP EVENT TRIGGER
DROP EVENT TRIGGER
DROP FUNCTION
DROP FUNCTION
DROP FUNCTION
DROP FUNCTION
psql:removeAllFRomDB.sql:98: ERROR:  cannot drop desired object(s) because other objects depend on them
DETAIL:  event trigger triggerddlcommandsqldrop depends on function classdb.logddlactivity()

Should DROP EVENT TRIGGER IF EXISTS triggerDDLCommandSqlDrop; be added to the uninstall? Likewise, should the accompanying triggerDDLCommandEnd also be added? These two triggers are defined in addDDLActivityLoggingReco.sql

Also a couple of minor comment observations:

• L 21: databse -> database
• L 111: Is this comment still relevant?

[wildtayne]

Thanks for pointing this out @afig. I had somehow pasted the wrong names for the event triggers in the DROP EVENT TRIGGER statements. The latest commit should fix this.

triggerDDLCommandSqlDrop and triggerDDLCommandEnd are the correct triggers to drop