Greg Stark <[EMAIL PROTECTED]> writes:
> So I think Phase I should look like:
> An ALTER TABLE command to make an inherited table "abstract" in the object
> oriented sense. That is, no records can be inserted in the parent table. If
> you follow the oracle model this is also where you specify the partition
> key. There's no index associated with this partition key though.
Check.
> A command to create a new partition, essentially syntactic sugar for a
> CREATE TABLE with an implied INHERITS clause and a constraint on the
> partition key. If you follow the oracle model then you explicitly specify
> which range or specific value of the partition key this partition holds.
Check.
> A command to remove a partition from the partitioned table and turn it into
> a regular table.
Ugh. Why? You can access the table directly anyway.
> A command to take a regular table and turn it into a partition.
Double ugh. Verifying that the table matches the partition scheme seems
like a lot of ugly, bug-prone, unnecessary code. What's the use case
for this anyway?
Those last two are *certainly* not Phase I requirements, and I don't
think we need them at all ever.
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
