Lists: | pgsql-hackers |
---|
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 |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
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
Attachment | Content-Type | Size |
---|---|---|
tt2v3-pgupgrade-composite-col.patch | text/plain | 9.2 KB |
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 |
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
From: | Noah Misch <noah(at)leadboat(dot)com> |
---|---|
To: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: ALTER TYPE DROP + composite-typed col vs. pg_upgrade |
Date: | 2011-05-22 00:10:50 |
Message-ID: | 20110522001050.GA32364@tornado.gateway.2wire.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-hackers |
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.