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 <snaga@uptime.jp > >>> <mailto:snaga@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.
