Skip site navigation (1) Skip section navigation (2)

Re: error-free disabling of individual child partition

From: Greg Stark <gsstark(at)mit(dot)edu>
To: Greg Stark <gsstark(at)MIT(dot)EDU>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: error-free disabling of individual child partition
Date: 2006-05-31 19:49:21
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers

Regarding ALTER TABLE ADD INHERITS, tablecmds.c has the following comment for
when it's creating a table that inherits some columns:

 *	  The order in which the attributes are inherited is very important.
 *	  Intuitively, the inherited attributes should come first. If a table
 *	  inherits from multiple parents, the order of those attributes are
 *	  according to the order of the parents specified in CREATE TABLE.

If you add a parent table at some later date then the columns might not fit
this constraint. Is it actually "very important" or merely a good idea for the
server to create them in the order the user will expect? That is, is anything
else in the server going to break if the columns aren't in the right order?

Actually now that I think of it removing a parent table can also create a
"incorrectly" ordered column list if the table has multiple parents. If we
remove one of its first parents and one of the columns was merged from
multiple parents then it will appear before its normal place with the other
columns from the later parent.

Incidentally, did the following message ever make it to the list? I saw my
carbon copy, but never received it from the list and never received any
responses. Usually any suggestion of making tokens reserved words elicits
screams of objections.

Greg Stark <gsstark(at)MIT(dot)EDU> writes:

> Tom Lane:
> > ALTER TABLE childN DROP INHERITS old_parent;
> > ALTER TABLE childN ADD INHERITS new_parent;
> I think you would have to make INHERITS a reserved word to make that happen:
> stark=> create table integer (i integer);
> stark=> alter table test add inherits integer;
> -- 
> greg


In response to


pgsql-hackers by date

Next:From: Dave PageDate: 2006-05-31 19:55:17
Subject: Re: Possible TODO item: copy to/from pipe
Previous:From: Tom LaneDate: 2006-05-31 19:45:47
Subject: More thoughts about planner's cost estimates

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group