Hi,
On 3/6/07, Peter Eisentraut <peter_e@gmx.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