2013/9/16 Satoshi Nagayasu <sn...@uptime.jp> > (2013/07/06 1:16), Pavel Stehule wrote: > >> 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. > > Any comments? > > Regards, > -- > Satoshi Nagayasu <sn...@uptime.jp> > Uptime Technologies, LLC. http://www.uptime.jp >
