Re: BUG #6704: ALTER EXTENSION postgis SET SCHEMA leaves dangling relations

Here's a cleaned up version of this patch, for HEAD. (The patches for
9.1 and 9.2 required minor conflict fixes, but nothing substantial).

The main difference from Dimitri's patch is that I added enough support
code so that AlterRelationNamespaceInternal() is always getting a valid
ObjectAddresses list, and get rid of the checks for a NULL one. It
seems cleaner and simpler to me this way. This means I had to add
support for object types that may never be visited more than once
(indexes), but I don't think this is a problem.

Remaining object types are those that use the generic code path in HEAD
(as patched by KaiGai). We know (because the generic code path checks)
that in these cases, relations are never involved; the only other funny
cases I saw were collations and functions, but those are funny only
because the lookups are unlike the normal cases; they don't have any
subsidiary objects that would cause trouble.

While I am looking at this code: I am uneasy about
AlterObjectNamespace_oid() ignoring object classes that it doesn't
explicitely know about. This means we will fail to cover new cases we
might come up with. For example, can we have event triggers in
extensions, and do event triggers belong to a schema? If so, we already
have a bug here in HEAD. I would like us to get rid of the "default:
break;" case, and instead explicitely list the object classes we ignore.
That way, the compiler will warn us as soon as we add a new object
class and neglect to add it here.

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