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

Pavel Stehule <pavel.stehule@gmail.com>

From: Pavel Stehule <pavel.stehule@gmail.com>
To: Dean Rasheed <dean.a.rasheed@gmail.com>
Cc: Peter Eisentraut <peter_e@gmx.net>, PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Date: 2013-12-07T21:34:00Z
Lists: pgsql-bugs, pgsql-hackers

Attachments

Hello

2013/12/5 Dean Rasheed <dean.a.rasheed@gmail.com>

> On 5 December 2013 10:06, Pavel Stehule <pavel.stehule@gmail.com> wrote:
> >> I think #1175 is close to being ready for commit. Pavel, will you
> >> produce an updated patch based on our last discussion? I'll set this
> >> patch to waiting on author.
> >
> >
> > I expected so your version was a final. I have no problem to do other
> > enhancing (by me) , but I don't fully understand to your last proposal.
> Can
> > you specify it more, please?
> >
>
> Well I was basically proposing that does_not_exist_skipping() be
> enhanced to report on non-existent types that form part of the object
> specification. I think this would affect the CAST, FUNCTION, AGGREGATE
> and OPERATOR cases, but should be a fairly trivial extension to the
> code that you've already added.
>

ok, updated patch is in attachment


>
> It should be possible to make the notice text from DROP...IF EXISTS
> consistent with the error text from a plain DROP. For example consider
> cases like func_name(no_such_schema.typename) and
> func_name(existing_schema.no_such_type).
>

yes, it is possible, but I wouldn't enhance a scope of this patch, if it is
possible, please. I would to finish a --if-exist option for pg_dump a
pg_restore before (in this release cycle).

We can continue in cleaning DROP obj messages in next release, or maybe in
last commitfest - this functionality is not critical and is not complex.

Regards

Pavel


>
> Regards,
> Dean
>