I can agree, so DROP TRIGGER doesn't need a IF EXISTS clause when it is executed after DROP TABLE.
pg_dump -c produces: DROP TRIGGER jjj ON public.foo; DROP TABLE public.foo; DROP FUNCTION public.f1(); DROP EXTENSION plpgsql; DROP SCHEMA public; Is there some reason why we use explicitly DROP TRIGGER there? Regards Pavel 2013/10/15 Andres Freund <and...@2ndquadrant.com> > On 2013-10-15 00:23:15 +0200, Tomas Vondra wrote: > > Hi, > > > > On 14.10.2013 23:44, Andres Freund wrote: > > > On 2013-10-10 12:54:23 -0400, Andrew Dunstan wrote: > > >> On 09/19/2013 06:12 PM, Pavel Stehule wrote: > > >>> 2013/9/16 Satoshi Nagayasu <sn...@uptime.jp > > >>> <mailto:sn...@uptime.jp>> > > >>> > > >>> 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. > > >> > > >> This thread seems to have gone cold, but I'm inclined to agree with > > >> Pavel. If the table doesn't exist, neither does the trigger, and > > >> the whole point of the 'IF EXISTS' variants is to provide the > > >> ability to issue DROP commands that don't fail if their target is > > >> missing. > > > > > > -1, this seems to likely to just hide typos. > > > > Not sure I agree with your reasoning. Isn't that equally true for 'IF > > EXISTS' clause with all commands in general? Why should we use "likely > > to hide typos" argument in this case and not the others? > > Because there simply is no reason to issue a DROP TRIGGER IF EXISTS if > you don't need the contents of the table. In that case you can just > issue a DROP TABLE IF EXISTS and start anew. > > > The purpose of this patch was to add support for quiet "pg_restore > > --clean" and pg_restore should not do typos (if it does, we're in much > > deeper troubles I guess). > > Why does that even have to do anything for triggers? Emitting DROP TABLE > should be enough. > > Greetings, > > Andres Freund > > -- > Andres Freund http://www.2ndQuadrant.com/ > PostgreSQL Development, 24x7 Support, Training & Services > > > -- > Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-hackers >
