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?
Or do you object only to extending DROP TRIGGER IF EXISTS to "if table
and trigger exists"? It seems natural to me that "no table" => "no
trigger" so I'm fine with this interpretation, just like Andrew.
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).
If you're concerned about users doing typos, they may as well do typos
in the trigger name with exactly the same result (trigger not dropped
without any kind of error message).
I see no reason to support DROP TRIGGER IF EXISTS but restrict the IF
EXISTS clause only to the trigger on the grounds of typos.
So +1 from me, both to the patch and graceful handling of missing table.
kind regards
Tomas
