Here is the patch to fix that, as discussed.
diff --git i/src/bin/pg_dump/pg_dump.c w/src/bin/pg_dump/pg_dump.c
index c2f6180..afc7fd7 100644
--- i/src/bin/pg_dump/pg_dump.c
+++ w/src/bin/pg_dump/pg_dump.c
@@ -12004,7 +12004,11 @@ dumpTableSchema(Archive *fout, TableInfo *tbinfo)
UNLOGGED
Peter Eisentraut pete...@gmx.net writes:
Here is the patch to fix that, as discussed.
Looks sane --- I assume you tested it against the originally
complained-of scenario?
http://archives.postgresql.org/message-id/201103111328.p2bdsfd10...@momjian.us
If so, please apply soon --- we need to wrap
On Wed, Apr 27, 2011 at 09:30:41PM +0300, Peter Eisentraut wrote:
Here is the patch to fix that, as discussed.
Looks correct. Thanks.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Wed, Mar 30, 2011 at 09:32:08PM -0400, Noah Misch wrote:
... ALTER TYPE mistakenly
only touches the first table-of-type:
create type t as (x int, y int);
create table is_a of t;
create table is_a2 of t;
alter type t drop attribute y cascade, add attribute z int cascade;
\d is_a
On Wed, Mar 30, 2011 at 9:32 PM, Noah Misch n...@leadboat.com wrote:
Incidentally, this led me to notice that you can hang a typed
table off a table row type. ALTER TABLE never propagates to such typed
tables,
allowing them to get out of sync:
create table t (x int, y int);
create table
On Wed, Mar 30, 2011 at 12:50 PM, Peter Eisentraut pete...@gmx.net wrote:
On tor, 2011-02-10 at 06:31 +0200, Peter Eisentraut wrote:
ERROR: cannot drop column from typed table
which probably is because test_type2 has a dropped column.
It should call
ALTER TYPE test_type2 DROP ATTRIBUTE
On Fri, Apr 08, 2011 at 03:43:39PM -0400, Robert Haas wrote:
On Wed, Mar 30, 2011 at 9:32 PM, Noah Misch n...@leadboat.com wrote:
Incidentally, this led me to notice that you can hang a typed
table off a table row type. ?ALTER TABLE never propagates to such typed
tables,
allowing them to
On ons, 2011-04-06 at 11:49 -0400, Noah Misch wrote:
Peter, were you planning to complete this? I can take a swing at it, if it
would be helpful.
Help is always welcome.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
On Tue, Apr 05, 2011 at 09:44:44AM -0400, Robert Haas wrote:
On Wed, Mar 30, 2011 at 9:32 PM, Noah Misch n...@leadboat.com wrote:
On Wed, Mar 30, 2011 at 07:50:12PM +0300, Peter Eisentraut wrote:
Here is a patch that addresses this problem.
This only works when exactly one typed table
On Wed, Mar 30, 2011 at 9:32 PM, Noah Misch n...@leadboat.com wrote:
On Wed, Mar 30, 2011 at 07:50:12PM +0300, Peter Eisentraut wrote:
On tor, 2011-02-10 at 06:31 +0200, Peter Eisentraut wrote:
ERROR: cannot drop column from typed table
which probably is because test_type2 has a
On tor, 2011-02-10 at 06:31 +0200, Peter Eisentraut wrote:
ERROR: cannot drop column from typed table
which probably is because test_type2 has a dropped column.
It should call
ALTER TYPE test_type2 DROP ATTRIBUTE xyz CASCADE;
instead. That will propagate to the table.
Here is a
On Wed, Mar 30, 2011 at 07:50:12PM +0300, Peter Eisentraut wrote:
On tor, 2011-02-10 at 06:31 +0200, Peter Eisentraut wrote:
ERROR: cannot drop column from typed table
which probably is because test_type2 has a dropped column.
It should call
ALTER TYPE test_type2 DROP
On Fri, Mar 11, 2011 at 8:28 AM, Bruce Momjian br...@momjian.us wrote:
Is this still an open bug?
Is anyone working on fixing this?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
Is this still an open bug?
---
Tom Lane wrote:
I find that pg_upgrade fails in HEAD when asked to do a 9.1-to-9.1
upgrade of the regression database. It gets to this bit of the
restore script:
CREATE TABLE test_tbl2
I find that pg_upgrade fails in HEAD when asked to do a 9.1-to-9.1
upgrade of the regression database. It gets to this bit of the
restore script:
CREATE TABLE test_tbl2 OF public.test_type2;
-- For binary upgrade, recreate dropped column.
UPDATE pg_catalog.pg_attribute
SET attlen = -1, attalign
Tom Lane wrote:
I find that pg_upgrade fails in HEAD when asked to do a 9.1-to-9.1
upgrade of the regression database. It gets to this bit of the
restore script:
CREATE TABLE test_tbl2 OF public.test_type2;
-- For binary upgrade, recreate dropped column.
UPDATE pg_catalog.pg_attribute
On ons, 2011-02-09 at 18:43 -0500, Tom Lane wrote:
I find that pg_upgrade fails in HEAD when asked to do a 9.1-to-9.1
upgrade of the regression database. It gets to this bit of the
restore script:
CREATE TABLE test_tbl2 OF public.test_type2;
-- For binary upgrade, recreate dropped
On ons, 2011-02-09 at 23:16 -0500, Bruce Momjian wrote:
I am not aware of this code changing in 9.1. Was this test in 9.0?
Does this problem happen for 9.0?
No, because you can't drop anything from a typed table in 9.0.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
18 matches
Mail list logo
