[ 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.
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. Anyway, pg_dump is not the only tool
that might wish to use DROP IF EXISTS.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
