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
*
Greg Stark wrote:
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 [EMAIL PROTECTED]
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);
CREATE TABLE
stark= alter table test add inherits integer;
ALTER TABLE
--
Added to TODO:
o Add ALTER TABLE tab ADD/DROP INHERITS parent
Sounds good, more inline with add/drop constraint.
pg_attribute.attislocal has to be set to 'false' for ADD,
and
attislocal: If you set this to False, you wouldn't be able to set it
back again.
Just curious,
Ühel kenal päeval, K, 2006-05-24 kell 09:56, kirjutas Zeugswetter
Andreas DCP SD:
Added to TODO:
o Add ALTER TABLE tab ADD/DROP INHERITS parent
Sounds good, more inline with add/drop constraint.
pg_attribute.attislocal has to be set to 'false' for ADD,
and
Ühel kenal päeval, T, 2006-05-23 kell 18:48, kirjutas Simon Riggs:
2. attislocal is always set False when an appropriate ADD INHERITS is
actioned. Not ever set back again.
Why never set back again ? I'd guess that it should be set back to
true when it is not an inherited column anymore, that
On Wed, 2006-05-24 at 11:17 +0300, Hannu Krosing wrote:
Ühel kenal päeval, T, 2006-05-23 kell 18:48, kirjutas Simon Riggs:
2. attislocal is always set False when an appropriate ADD INHERITS is
actioned. Not ever set back again.
Why never set back again ? I'd guess that it should be
Simon Riggs [EMAIL PROTECTED] writes:
On Wed, 2006-05-24 at 11:17 +0300, Hannu Krosing wrote:
Why never set back again ? I'd guess that it should be set back to
true when it is not an inherited column anymore, that is when its
attinhcount reaches zero.
Because you have no record of whether
Ühel kenal päeval, K, 2006-05-24 kell 09:40, kirjutas Tom Lane:
Simon Riggs [EMAIL PROTECTED] writes:
On Wed, 2006-05-24 at 11:17 +0300, Hannu Krosing wrote:
Why never set back again ? I'd guess that it should be set back to
true when it is not an inherited column anymore, that is when its
Hannu Krosing wrote:
Ühel kenal päeval, K, 2006-05-24 kell 09:40, kirjutas Tom Lane:
Simon Riggs [EMAIL PROTECTED] writes:
On Wed, 2006-05-24 at 11:17 +0300, Hannu Krosing wrote:
Why never set back again ? I'd guess that it should be set back to
true when it is not an inherited column
Hannu Krosing wrote:
I don't think that LIKE inheritance is inheritance at all, rather it is
a create-time macro.
Right. It's actually quite useful. I'd like to see it made available in
a couple of other contexts, such as CREATE TYPE and the type expression
needed when calling a
Alvaro Herrera [EMAIL PROTECTED] writes:
Hannu Krosing wrote:
I don't think that LIKE inheritance is inheritance at all, rather it is
a create-time macro.
In that case the columns should be marked attislocal.
Right.
regards, tom lane
---(end
On Wed, 2006-05-24 at 09:40 -0400, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
On Wed, 2006-05-24 at 11:17 +0300, Hannu Krosing wrote:
Why never set back again ? I'd guess that it should be set back to
true when it is not an inherited column anymore, that is when its
attinhcount
table of another table. I propose a TODO item to allow this:
ALTER TABLE childN INHERITS ( parent1, ... );
We don't need a disinherit do we?
I propose: ALTER TABLE childN INHERITS ();
Thus I also think, that the list should be complete, and is not an
addition
to existing
On Tue, 2006-05-23 at 09:49 +0200, Zeugswetter Andreas DCP SD wrote:
table of another table. I propose a TODO item to allow this:
ALTER TABLE childN INHERITS ( parent1, ... );
We don't need a disinherit do we?
I propose: ALTER TABLE childN INHERITS ();
Thus I also think, that
Ühel kenal päeval, T, 2006-05-23 kell 10:51, kirjutas Simon Riggs:
On Tue, 2006-05-23 at 09:49 +0200, Zeugswetter Andreas DCP SD wrote:
table of another table. I propose a TODO item to allow this:
ALTER TABLE childN INHERITS ( parent1, ... );
We don't need a disinherit
Zeugswetter Andreas DCP SD [EMAIL PROTECTED] writes:
We don't need a disinherit do we?
I propose: ALTER TABLE childN INHERITS ();
Thus I also think, that the list should be complete, and is not an
addition to existing inheritance.
Don't like that at all: it seems far too error-prone.
Ühel kenal päeval, T, 2006-05-23 kell 09:37, kirjutas Tom Lane:
Zeugswetter Andreas DCP SD [EMAIL PROTECTED] writes:
We don't need a disinherit do we?
I propose: ALTER TABLE childN INHERITS ();
Thus I also think, that the list should be complete, and is not an
addition to existing
On Tue, 2006-05-23 at 09:37 -0400, Tom Lane wrote:
Zeugswetter Andreas DCP SD [EMAIL PROTECTED] writes:
We don't need a disinherit do we?
I propose: ALTER TABLE childN INHERITS ();
Thus I also think, that the list should be complete, and is not an
addition to existing inheritance.
ALTER TABLE childN ALTER INHERITS DROP (parent);
ALTER TABLE childN ALTER INHERITS ADD (parent);
Wouldn't it be possible to allow the ADD/DROP to happen in the same
statement, like:
ALTER TABLE childN ALTER INHERITS DROP crt_parent ADD new_parent;
or:
ALTER TABLE childN ALTER INHERITS DROP
On Tue, 2006-05-23 at 16:29 +0200, Csaba Nagy wrote:
ALTER TABLE childN ALTER INHERITS DROP (parent);
ALTER TABLE childN ALTER INHERITS ADD (parent);
Wouldn't it be possible to allow the ADD/DROP to happen in the same
statement, like:
ALTER TABLE childN ALTER INHERITS DROP crt_parent
Ühel kenal päeval, T, 2006-05-23 kell 15:59, kirjutas Simon Riggs:
On Tue, 2006-05-23 at 16:29 +0200, Csaba Nagy wrote:
ALTER TABLE childN ALTER INHERITS DROP (parent);
ALTER TABLE childN ALTER INHERITS ADD (parent);
Wouldn't it be possible to allow the ADD/DROP to happen in the same
On Tue, 2006-05-23 at 18:19 +0300, Hannu Krosing wrote:
For me DROP INHERITS oldtable sounds better than INHERITS DROP
oldtable , but it may be just me :)
Agreed, so proposal is now
ALTER TABLE childN DROP INHERITS old_parent;
ALTER TABLE childN ADD INHERITS new_parent;
Going once; going
Simon Riggs [EMAIL PROTECTED] writes:
Do we need the ALTER keyword? That isn't used anywhere apart from
manipulating columns. i.e.
ALTER TABLE childN INHERITS DROP old_parent;
ALTER TABLE childN INHERITS ADD new_parent;
At that point it seems like it'd read more naturally the other way
On Tue, 2006-05-23 at 11:31 -0400, Tom Lane wrote:
At that point it seems like it'd read more naturally the other way
round:
ALTER TABLE childN DROP INHERITS old_parent;
ALTER TABLE childN ADD INHERITS new_parent;
although I'm not sure if this would create a parser conflict against
Simon Riggs [EMAIL PROTECTED] writes:
- ADD/DROP are opposites; you can use the other one to undo an action
taken in haste, error etc
It's not going to be that easy. What exactly will happen to the child
table's attislocal/attinhcount settings, and why, during ADD or DROP?
On Tue, 2006-05-23 at 13:17 -0400, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
- ADD/DROP are opposites; you can use the other one to undo an action
taken in haste, error etc
It's not going to be that easy. What exactly will happen to the child
table's attislocal/attinhcount
Added to TODO:
o Add ALTER TABLE tab ADD/DROP INHERITS parent
pg_attribute.attislocal has to be set to 'false' for ADD, and
pg_attribute.attinhcount adjusted appropriately
---
Simon Riggs
It comes up repeatedly that I need to load fresh data into a new
table, build indexes and vacuum - then drop the old table and
substitute the new.
Deleting old and inserting new records is too slow - not to mention
the vaccuming. Loading with COPY, then building indexes, then
vacuuming is very
On Mon, May 22, 2006 at 02:25:09PM -0400, April Lorenzen wrote:
It comes up repeatedly that I need to load fresh data into a new
table, build indexes and vacuum - then drop the old table and
substitute the new.
Why are you vacuuming a brand new table? Just run analyze.
Postgresql partioning
Jim C. Nasby wrote:
BEGIN;
-- Don't do the drop right now, because it might take awhile
ALTER TABLE tablename RENAME TO delete_tablename;
ALTER TABLE temporary_tablename RENAME TO tablename;
COMMIT;
DROP delete_tablename;
What if there are dependencies? Might be better to have a view,
On Mon, May 22, 2006 at 03:28:39PM -0400, Andrew Dunstan wrote:
Jim C. Nasby wrote:
BEGIN;
-- Don't do the drop right now, because it might take awhile
ALTER TABLE tablename RENAME TO delete_tablename;
ALTER TABLE temporary_tablename RENAME TO tablename;
COMMIT;
DROP delete_tablename;
Jim C. Nasby wrote:
On Mon, May 22, 2006 at 03:28:39PM -0400, Andrew Dunstan wrote:
Jim C. Nasby wrote:
BEGIN;
-- Don't do the drop right now, because it might take awhile
ALTER TABLE tablename RENAME TO delete_tablename;
ALTER TABLE temporary_tablename RENAME TO tablename;
COMMIT;
On Mon, 2006-05-22 at 14:25 -0400, April Lorenzen wrote:
Postgresql partioning makes this all almost possible: the master
automatically SELECTs from all the child tables - so it automatically
recoginize the new ones, and no loss when the old ones are dropped.
Just one thing would make it
Simon Riggs wrote:
There is not currently any way to make an existing table become a child
table of another table. I propose a TODO item to allow this:
ALTER TABLE childN INHERITS ( parent1, ... );
This would only succeed if all of the columns that would have been
inherited from all
35 matches
Mail list logo
