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]> w
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
*
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
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
>
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
-
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 functio
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
Ü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
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 o
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 s
Ü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,
Ü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,
> a
> 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 c
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 wrote
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/attin
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 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:
> 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 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
Ü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
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_p
> 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 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 inh
Hannu Krosing <[EMAIL PROTECTED]> writes:
> Ãhel kenal päeval, T, 2006-05-23 kell 09:37, kirjutas Tom Lane:
>>> 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
Ü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
"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 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
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 als
> > 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 inh
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 pa
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 i
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;
DROP
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_
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, whic
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 partion
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 fa
36 matches
Mail list logo
