Re: Auto creation of Partitions - Mailing list pgsql-hackers

From NikhilS
Subject Re: Auto creation of Partitions
Date
Msg-id d3c4af540703092058j5c288cb3y6b61bddea53a1bfa@mail.gmail.com
Whole thread Raw
In response to Re: Auto creation of Partitions  (Hannu Krosing <hannu@skype.net>)
List pgsql-hackers
Hi,

On 3/10/07, Hannu Krosing <hannu@skype.net> wrote:
Ühel kenal päeval, R, 2007-03-09 kell 15:41, kirjutas Jim Nasby:
> On Mar 9, 2007, at 3:31 AM, Zeugswetter Andreas ADI SD wrote:
> >>> Since partition is inheritance-based, a simple DROP or  "NO
> >> INHERIT"
> >>> will do the job to deal with the partition. Do we want to reinvent
> >>> additional syntax when these are around and are documented?
> >>
> >> Well, if the syntax for adding a new partition eventually
> >> ends up as ALTER TABLE ADD PARTITION, then it would make more
> >> sense that you remove a partition via ALTER TABLE DROP PARTITION.
> >
> > But DROP PARTITION usually moves the data from this partition to other
> > partitions,
> > so it is something different.
>
> It does? IIRC every partitioning system I've seen DROP PARTITION
> drops the data as well. It's up to you to move it somewhere else if
> you want to keep it.

Will this proposed DROP PARTITION just disassociate the table from the
master, or will it actually drop the partitions table from the whole
database ?
 
Thats why I would prefer the existing mechanism, there a DROP on the child removes it and a NO INHERIT disassociates it. There might be situations where we would want to just disassociate and not drop.
 
Regards,
Nikhils

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





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

pgsql-hackers by date:

Previous
From: Robert Treat
Date:
Subject: Re: Auto creation of Partitions
Next
From: NikhilS
Date:
Subject: Re: Auto creation of Partitions