Re: ALTER TYPE 2: skip already-provable no-work rewrites

Robert Haas <robertmhaas@gmail.com>

From: Robert Haas <robertmhaas@gmail.com>
To: Noah Misch <noah@leadboat.com>
Cc: pgsql-hackers@postgresql.org
Date: 2011-02-05T15:03:59Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →
  1. Change ALTER TABLE SET WITHOUT OIDS to rewrite the whole table to physically

On Thu, Jan 27, 2011 at 2:48 PM, Noah Misch <noah@leadboat.com> wrote:
> Done as attached.

Looking at this still more, it appears that independent of any change
this patch may wish to make, there's a live bug here related to the
foreign table patch I committed back in December.  Creating a foreign
table creates an eponymous rowtype, which can be used as a column in a
regular table.  You can then change the data type of a column in the
foreign table, read from the regular table, and crash the server.

The simple fix for this is to just change the code in
ATPrepAlterColumnType to handle the foreign table case also:

    if (tab->relkind == RELKIND_COMPOSITE_TYPE)
    {
        /*
         * For composite types, do this check now.  Tables will check
         * it later when the table is being rewritten.
         */
        find_composite_type_dependencies(rel->rd_rel->reltype,
                                         NULL,
                                         RelationGetRelationName(rel));
    }

But this is a little unsatisfying, for two reasons.  First, the error
message will be subtly wrong: we can make it complain about a table or
a type, but not a foreign table.  At a quick look, it likes the right
fix might be to replace the second and third arguments to
find_composite_type_dependencies() with a Relation.  Second, I wonder
if we shouldn't refactor things so that all the checks fire in
ATRewriteTables() rather than doing them in different places.  Seems
like that might be cleaner.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company