I am sending a patch that removes strict requirements for DROP IF EXISTS statements. This behave is similar to our ALTER IF EXISTS behave now.
postgres=# DROP CAST IF EXISTS (sss AS public.casttesttype); NOTICE: types "sss" and "public.casttesttype" does not exist, skipping DROP CAST postgres=# DROP FUNCTION IF EXISTS public.pt_in_widget(point, widget); NOTICE: function public.pt_in_widget(point,widget) does not exist, skipping DROP FUNCTION postgres=# DROP OPERATOR IF EXISTS public.<% (point, widget); NOTICE: operator public.<% does not exist, skipping DROP OPERATOR postgres=# DROP TRIGGER test_trigger_exists ON no_such_table; ERROR: relation "no_such_table" does not exist postgres=# DROP TRIGGER IF EXISTS test_trigger_exists ON no_such_table; NOTICE: trigger "test_trigger_exists" for table "no_such_table" does not exist, skipping DROP TRIGGER
This functionality is necessary for correct quite reload from dump without possible warnings
I'm looking at this patch, and I have a question here.
Should "DROP TRIGGER IF EXISTS" ignore error for non-existing trigger and non-existing table? Or just only for non-existing trigger?
My opinion is so, both variants should be ignored - it should be fully fault tolerant in this use case.
Regards
Pavel
I've not understood the pg_restore issue precisely so far, but IMHO "DROP TRIGGER IF EXISTS" means "if the _trigger_ exists", not "if the _table_ exists".
Is this a correct and/or an expected behavior?
Sorry if I missed some consensus which we already made.