Thread

1. ALTER TYPE DROP + composite-typed col vs. pg_upgrade

   Noah Misch <noah@leadboat.com> — 2011-04-28T19:41:12Z

   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
   

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

   Heikki Linnakangas <heikki.linnakangas@enterprisedb.com> — 2011-05-21T12:25:30Z

   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
   
   

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

   Noah Misch <noah@leadboat.com> — 2011-05-22T00:10:50Z

   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.