Re: ALTER TYPE DROP + composite-typed col vs. pg_upgrade

From: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
To: Noah Misch <noah(at)leadboat(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: ALTER TYPE DROP + composite-typed col vs. pg_upgrade
Date: 2011-05-21 12:25:30
Message-ID: 4DD7AF3A.1070301@enterprisedb.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 28.04.2011 15:41, Noah Misch wrote:
> Now that we have ALTER TYPE DROP ATTRIBUTE, pg_dump --binary-upgrade must, for
> the sake of composite-typed columns, preserve the dropped-column configuration
> of stand-alone composite types. Here's a test case:
>
> create type t as (x int, y int);
> create table has_a (tcol t);
> insert into has_a values ('(1,2)');
> table has_a; -- (1,2)
> alter type t drop attribute y cascade, add attribute z int cascade;
> table has_a; -- (1,)
> table has_a; -- after pg_upgrade: (1,2)
>
> Apparently I did not fully test the last version after merging it with upstream
> changes, because it did not work. Sorry for that. This version updates the
> queries correctly and adds a test case. A regular "make check" passes the new
> test case with or without the rest of this patch. However, a comparison of
> regression database dumps before and after a pg_upgrade will reveal the problem
> given this new test case. See, for example, Peter's recent patch to have the
> contrib/pg_upgrade "make check" do this.

Ok, committed.

--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Fabien COELHO 2011-05-21 13:46:41 minor patch submission: CREATE CAST ... AS EXPLICIT
Previous Message Mark 2011-05-21 11:41:34 Re: ts_rank