• Tom Lane's avatar
    Further fix ALTER COLUMN TYPE's handling of indexes and index constraints. · f946a409
    Tom Lane authored
    This patch reverts all the code changes of commit e76de886, which turns
    out to have been seriously misguided.  We can't wait till later to compute
    the definition string for an index; we must capture that before applying
    the data type change for any column it depends on, else ruleutils.c will
    deliverr wrong/misleading results.  (This fine point was documented
    nowhere, of course.)
    
    I'd also managed to forget that ATExecAlterColumnType executes once per
    ALTER COLUMN TYPE clause, not once per statement; which resulted in the
    code being basically completely broken for any case in which multiple ALTER
    COLUMN TYPE clauses are applied to a table having non-constraint indexes
    that must be rebuilt.  Through very bad luck, none of the existing test
    cases nor the ones added by e76de886 caught that, but of course it was
    soon found in the field.
    
    The previous patch also had an implicit assumption that if a constraint's
    index had a dependency on a table column, so would the constraint --- but
    that isn't actually true, so it didn't fix such cases.
    
    Instead of trying to delete unneeded index dependencies later, do the
    is-there-a-constraint lookup immediately on seeing an index dependency,
    and switch to remembering the constraint if so.  In the unusual case of
    multiple column dependencies for a constraint index, this will result in
    duplicate constraint lookups, but that's not that horrible compared to all
    the other work that happens here.  Besides, such cases did not work at all
    before, so it's hard to argue that they're performance-critical for anyone.
    
    Per bug #15865 from Keith Fiske.  As before, back-patch to all supported
    branches.
    
    Discussion: https://postgr.es/m/15865-17940eacc8f8b081@postgresql.org
    f946a409
tablecmds.c 506 KB