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

From: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
To: Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com>
Cc: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, Peter Eisentraut <peter_e(at)gmx(dot)net>, 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: 2014-01-21 22:28:51
Message-ID: 20140121222851.GL10723@eldon.alvh.no-ip.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs pgsql-hackers

I have been mulling over this patch, and I can't seem to come to terms
with it. I first started making it look nicer here and there, thinking
it was all mostly okay, but eventually arrived at the idea that it seems
wrong to do what this does: basically, get_object_address() tries to
obtain an object address, and if that fails, return InvalidOid; then, in
RemoveObjects, we try rather hard to figure out why that failed, and
construct an error message.

It seems to me that it would make more sense to have get_object_address
somehow return a code indicating what failed; then we don't have to go
all over through the parser code once more. Perhaps, for example, when
missing_ok is given as true to get_object_address it also needs to get a
pointer to ObjectType and a string; if some object does not exist then
fill the ObjectType with the failing object and the string with the
failing name. Then RemoveObjects can construct a string more easily.
Not sure how workable this exact idea is; maybe there is a better way.

--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Marko Tiikkaja 2014-01-22 01:19:34 Re: BUG #8870: PL/PgSQL, SELECT .. INTO and the number of result columns
Previous Message Bruce Momjian 2014-01-21 21:53:05 Re: BUG #7730: intarray representation of empty arrays

Browse pgsql-hackers by date

  From Date Subject
Next Message Adrian Klaver 2014-01-21 22:51:52 Re: Incorrectly reporting config errors
Previous Message Martín Marqués 2014-01-21 22:19:48 yum psycopg2 doc package not signed