Skip site navigation (1) Skip section navigation (2)

ALTER TYPE DROP + composite-typed col vs. pg_upgrade

From: Noah Misch <noah(at)leadboat(dot)com>
To: pgsql-hackers(at)postgresql(dot)org
Subject: ALTER TYPE DROP + composite-typed col vs. pg_upgrade
Date: 2011-04-28 19:41:12
Message-ID: 20110428194112.GB12161@tornado.leadboat.com (view raw or flat)
Thread:
Lists: pgsql-hackers
As originally noted here:
http://archives.postgresql.org/message-id/20110329215043.GA11023@tornado.gateway.2wire.net

Previous version of patch proposed here:
http://archives.postgresql.org/message-id/20110418235041.GB2769@tornado.leadboat.com

This was a side issue to that thread, and its primary issue is now resolved.
Here's a fresh thread to finish this other bug.


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.

Thanks,
nm

Responses

pgsql-hackers by date

Next:From: Tom LaneDate: 2011-04-28 19:44:26
Subject: Re: pgsql: Fix pg_size_pretty() to avoid overflow for inputs close to INT64
Previous:From: Dave PageDate: 2011-04-28 19:33:44
Subject: Re: pgsql: Fix pg_size_pretty() to avoid overflow for inputs close to INT64

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group