On Thu, Jan 14, 2010 at 4:13 AM, Takahiro Itagaki
<itagaki.takahiro@oss.ntt.co.jp> wrote:
> Here is a revised partitioning syntax patch. It implements only syntax and
> on-disk structure mentioned below:
> Table Partitioning#Syntax
> http://wiki.postgresql.org/wiki/Table_partitioning#Syntax
> Table Partitioning#On-disk structure
> http://wiki.postgresql.org/wiki/Table_partitioning#On-disk_structure
>
> What we can do with the patch is src/test/regress/sql/partition.sql.
> Note that the patch does nothing about INSERTs; triggers are still needed.
>
> The main syntax is CREATE TABLE () PARTITION BY {RANGE | LIST} (...).
> The reason I use it rather than "PARTITIONED BY" is for compatibility
> to other DBMSs; Oracle and MySQL.
>
> Changes from the previous CommitFest are:
> - Additinal regression tests:
> 1000 partitions, error cases and boolean partitions
> - Use pg_inherits_parent_index index if available.
> - Sort not only range partitions but also list partitions
> for stable display order.
> - Remove ALTER PARTITION and DROP PARTITION syntax because
> they are just synonyms of ALTER TABLE and DROP TABLE.
A couple of preliminary comments on this:
1. If we're thinking that this syntax should eventually result in
inserts (and updates?) being redirected to the appropriate partition,
then I think we should have that in the initial version. I don't
think we really want to add the syntax with a plan to change its
behavior incompatibly down the road.
2. The documentation does not explain what partitioning by list or by
range means, or what the difference between the two is. I think some
kind of general introduction to the subject is essential.
3. This patch is large enough (+1951/-63) that we have to consider
whether it makes sense to merge it at this point in the release cycle.It doesn't change much existing code, which is a
pointin its favor,
but it's still a big patch. I guess we can wait until we're a little
further along to make that decision.
...Robert