Обсуждение: ALTER TYPE DROP + composite-typed col vs. pg_upgrade
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
Вложения
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
On Sat, May 21, 2011 at 08:25:30AM -0400, Heikki Linnakangas wrote: > 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. Thank you.