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
Peter Eisentraut 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 beta1 this even
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
On Fri, Apr 08, 2011 at 03:43:39PM -0400, Robert Haas wrote:
> On Wed, Mar 30, 2011 at 9:32 PM, Noah Misch 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
On Wed, Mar 30, 2011 at 12:50 PM, 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 ATTRIBU
On Wed, Mar 30, 2011 at 9:32 PM, Noah Misch 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 is_a of t;
>
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 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:
http://www.
On Tue, Apr 05, 2011 at 09:44:44AM -0400, Robert Haas wrote:
> On Wed, Mar 30, 2011 at 9:32 PM, Noah Misch 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 uses each c
On Wed, Mar 30, 2011 at 9:32 PM, Noah Misch 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 dropped c
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_t
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.
On Fri, Mar 11, 2011 at 8:28 AM, Bruce Momjian 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)
To make changes
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_t
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)
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
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_attr
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
18 matches
Mail list logo
