> > 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 inheritance.

>
> O, yes, I think we do. I can imagine that the ability to swap a table

Agreed. Simon, were you testing how many ppl read to the end :-)

Andreas

---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq

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 the list should be complete, and is not an
> addition
> to existing inheritance.

Sounds good; an absolute rather than a relative approach. Avoids new
keywords.

Implementation is simpler too:
- check that we have all required merged attributes (if any)
- remove any inheritance that isn't on the list

If the table is already INHERITS (x) and we specify INHERITS (x) then
its a no-op that returns success.

> > O, yes, I think we do. I can imagine that the ability to swap a table
>
> Agreed. Simon, were you testing how many ppl read to the end :-)

Just seeing who cared. DROP TABLE removes inheritance too, in a Keyser
Soze manner.

--
Simon Riggs
EnterpriseDB http://www.enterprisedb.com


---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

http://archives.postgresql.org

Ü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 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.
>
> Sounds good; an absolute rather than a relative approach. Avoids new
> keywords.

And also allows you move a partition from live to archive table in one
command. Brilliant

> Implementation is simpler too:
> - check that we have all required merged attributes (if any)
> - remove any inheritance that isn't on the list
>
> If the table is already INHERITS (x) and we specify INHERITS (x) then
> its a no-op that returns success.
>
> > > O, yes, I think we do. I can imagine that the ability to swap a table
> >
> > Agreed. Simon, were you testing how many ppl read to the end :-)
>
> Just seeing who cared. DROP TABLE removes inheritance too, in a Keyser
> Soze manner.

Just fyi - I care too .

--
----------------
Hannu Krosing
Database Architect
Skype Technologies OÜ
Akadeemia tee 21 F, Tallinn, 12618, Estonia

Skype me: callto:hkrosing
Get Skype for free: http://www.skype.com




---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match

"Zeugswetter Andreas DCP SD" <ZeugswetterA@spardat.at> 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.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

Ühel kenal päeval, T, 2006-05-23 kell 09:37, kirjutas Tom Lane:
> "Zeugswetter Andreas DCP SD" <ZeugswetterA@spardat.at> 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.

In what way ?

Do you mean that it will be easy for the user to make errors, od do yuo
think that it will be hard to implement in a robust way ?

In the first case, I'd propose following syntax

ALTER TABLE childN ALTER INHERITS DROP (parent);
ALTER TABLE childN ALTER INHERITS ADD (parent);

With this syntax reparenting would need an explicit transaction and two
"ALTER TABLE ... ALTER INHERITS ..." commands, but it is (arguably)
harder to make mistakes.

--
----------------
Hannu Krosing
Database Architect
Skype Technologies OÜ
Akadeemia tee 21 F, Tallinn, 12618, Estonia

Skype me: callto:hkrosing
Get Skype for free: http://www.skype.com



---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match

Hannu Krosing <hannu@skype.net> 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 seems far too error-prone.

> In what way ?

It seems like it'd be awfully easy to unintentionally disinherit a child
table from a parent.

In a situation where you're only using single inheritance, it hardly
matters of course, but for multiple inheritance it just seems like a
way to shoot yourself in the foot. ISTM it'd be safer to have an
explicit disinherit-from-this-parent operation.

> In the first case, I'd propose following syntax

> ALTER TABLE childN ALTER INHERITS DROP (parent);
> ALTER TABLE childN ALTER INHERITS ADD (parent);

I could live with that. Do we need the parens?

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq

On Tue, 2006-05-23 at 09:37 -0400, Tom Lane wrote:
> "Zeugswetter Andreas DCP SD" <ZeugswetterA@spardat.at> 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.

What types of error do you think its prone to?

Can you say what you would prefer?

As ever, not that worried about syntax, but I would like to get
agreement on a specific way forward now we're discussing this.

--
Simon Riggs
EnterpriseDB http://www.enterprisedb.com


---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

> 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 crt_parent, ALTER INHERITS ADD
new_parent;

That would still make it one statement, but more explicit. And it would
eliminate the need for parenthesis (I assume they were needed for
supplying more than 1 table to inherit/disinherit).

Cheers,
Csaba.




---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly

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 ADD new_parent;
>
> or:
>
> ALTER TABLE childN ALTER INHERITS DROP crt_parent, ALTER INHERITS ADD
> new_parent;
>
> That would still make it one statement, but more explicit. And it would
> eliminate the need for parenthesis (I assume they were needed for
> supplying more than 1 table to inherit/disinherit).

Sounds good.

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;

--
Simon Riggs
EnterpriseDB http://www.enterprisedb.com


---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq

Ü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
> > statement, like:
> >
> > ALTER TABLE childN ALTER INHERITS DROP crt_parent ADD new_parent;
> >
> > or:
> >
> > ALTER TABLE childN ALTER INHERITS DROP crt_parent, ALTER INHERITS ADD
> > new_parent;
> >
> > That would still make it one statement, but more explicit. And it would
> > eliminate the need for parenthesis (I assume they were needed for
> > supplying more than 1 table to inherit/disinherit).
>
> Sounds good.
>
> Do we need the ALTER keyword?

Probably not.

> 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;

For me "DROP INHERITS oldtable" sounds better than "INHERITS DROP
oldtable" , but it may be just me

--
----------------
Hannu Krosing
Database Architect
Skype Technologies OÜ
Akadeemia tee 21 F, Tallinn, 12618, Estonia

Skype me: callto:hkrosing
Get Skype for free: http://www.skype.com

NOTICE: This communication contains privileged or other confidential
information. If you have received it in error, please advise the sender
by reply email and immediately delete the message and any attachments
without copying or disclosing the contents.


---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster