• A
    Fix ALTER EXTENSION / SET SCHEMA · 04f28bdb
    Alvaro Herrera 提交于
    In its original conception, it was leaving some objects into the old
    schema, but without their proper pg_depend entries; this meant that the
    old schema could be dropped, causing future pg_dump calls to fail on the
    affected database.  This was originally reported by Jeff Frost as #6704;
    there have been other complaints elsewhere that can probably be traced
    to this bug.
    
    To fix, be more consistent about altering a table's subsidiary objects
    along the table itself; this requires some restructuring in how tables
    are relocated when altering an extension -- hence the new
    AlterTableNamespaceInternal routine which encapsulates it for both the
    ALTER TABLE and the ALTER EXTENSION cases.
    
    There was another bug lurking here, which was unmasked after fixing the
    previous one: certain objects would be reached twice via the dependency
    graph, and the second attempt to move them would cause the entire
    operation to fail.  Per discussion, it seems the best fix for this is to
    do more careful tracking of objects already moved: we now maintain a
    list of moved objects, to avoid attempting to do it twice for the same
    object.
    
    Authors: Alvaro Herrera, Dimitri Fontaine
    Reviewed by Tom Lane
    04f28bdb
pg_constraint.c 26.2 KB