(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?
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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
