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.
Greetings,
Andres Freund
-- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services
