On 2013-11-10 16:28:27 -0500, Tom Lane wrote: > [ catching up on old email ] > > Andres Freund <and...@2ndquadrant.com> writes: > > On 2013-10-15 00:23:15 +0200, Tomas Vondra wrote: > >> On 2013-10-10 12:54:23 -0400, Andrew Dunstan wrote: > >>> 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. > > > 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. > > I think this is nonsense. It's only one step removed from "why do you > need IF EXISTS at all, you should know whether the object is there". > The entire point of this syntax is to not need to do detailed analysis > about whether the object is there.
Well, in my opinion the IF EXISTS refers to the object type being dropped. I.e. with DROP TABLE it refers to the table not existing, with DROP TRIGGER it refers to the trigger not existing. Note how we also error out if you do something like: ALTER TABLE nonexistant DROP COLUMN IF EXISTS bar; > The pg_dump --clean use-case is sufficient refutation for that, IMO. > You're suggesting that pg_dump should make a special case out of what it > emits for "cleaning" a trigger; which we could do I guess, but it would be > ugly and fragile. For instance, the special case would probably soon grow > some warts for partial-dump scenarios. ISTM the only way to get a DROP TRIGGER that actually is required is a --section=post-data dump. In the other cases it will get dropped by the DROP TABLE that's executed shortly afterwards. But in that case we'll currently error out during the CREATE TRIGGER shortly afterwards if the table doesn't exist... Maybe the way to fix this properly is to not drop post-data objects that are implicitly dropped by the object that owns them. >Anyway, pg_dump is not the only tool that might wish to use DROP IF EXISTS. Well, I am absolutely not arguing against DROP TRIGGER IF NOT EXISTS (which we already have), just against it ignoring nonexistant tables instead of just nonexistant triggers. 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
