Re: Re: [BUGS] BUG #7873: pg_restore --clean tries to drop tables that don't exist

From: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
To: Andres Freund <andres(at)2ndquadrant(dot)com>
Cc: Tomas Vondra <tv(at)fuzzy(dot)cz>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Re: [BUGS] BUG #7873: pg_restore --clean tries to drop tables that don't exist
Date: 2013-11-11 19:57:51
Message-ID: CAFj8pRA2PjdE32Y1QZV+i9shbD0_Gw_zBnkjduV+LhLbv_pXGQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs pgsql-hackers

I can agree, so DROP TRIGGER doesn't need a IF EXISTS clause when it is
executed after DROP TABLE.

pg_dump -c produces:

DROP TRIGGER jjj ON public.foo;
DROP TABLE public.foo;
DROP FUNCTION public.f1();
DROP EXTENSION plpgsql;
DROP SCHEMA public;

Is there some reason why we use explicitly DROP TRIGGER there?

Regards

Pavel

2013/10/15 Andres Freund <andres(at)2ndquadrant(dot)com>

> 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(at)uptime(dot)jp
> > >>> <mailto:snaga(at)uptime(dot)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
>
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Pavel Stehule 2013-11-11 20:07:56 Re: Re: [BUGS] BUG #7873: pg_restore --clean tries to drop tables that don't exist
Previous Message Peter Eisentraut 2013-11-11 19:26:30 Re: BUG #8588: Need work arounds for Apple unaligned access

Browse pgsql-hackers by date

  From Date Subject
Next Message Pavel Stehule 2013-11-11 20:07:56 Re: Re: [BUGS] BUG #7873: pg_restore --clean tries to drop tables that don't exist
Previous Message Tom Lane 2013-11-11 19:54:16 Re: all_visible replay aborting due to uninitialized pages