Re: Auto creation of Partitions

Hi,

On 3/6/07, Peter Eisentraut <peter_e(at)gmx(dot)net> wrote:
>
> NikhilS wrote:
> > iv) Based on the PRIMARY, UNIQUE, REFERENCES information specified,
> > pass it on to the children tables.
>
> How will you maintain a primary key in such a table, considering that
> indexes can't span multiple tables?

We will not (I know its a hard thing to do :) ), the intention is to use
this information from the parent and make it a property of the child table.
This will avoid the step for the user having to manually specify CREATE
INDEX and the likes on all the children tables one-by-one.

> 1) Whether we should use triggers/rules for step number (iii) above.
> > Maybe rules is the way to go.
>
> Since this would basically be a case of the updatable rules problem, you
> should review those discussions in the past to check whether the issues
> mentioned there don't interfere with that plan.

The rules mentioned here will be to specify that all the
inserts/updates/deletes should go into proper children tables instead of the
parent. I do not see the updateable rules problem with regards to this, but
will check out the archives for discussion on this related to partitioning.

> 2) What other attributes (access permissions e.g.) of the master
> > along with the ones specified in (iv) should be passed on to the
> > children.
>
> Moreover, how are later changes of those attributes propagated?

Once created, this will be a normal inheritance relationship between the
tables and all the existing commands will apply to both the parent and the
child.

The basic idea here is to automate as many things as possible at partition
creation time. The user is free to make additional changes to the involved
tables later too.

Regards,
Nikhils

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