Hello Anastasia,
My 0.02 €:
> The patch implements following syntax:
>
> CREATE TABLE ... PARTITION BY partition_method (list_of_columns)
> partition_auto_create_clause
>
> where partition_auto_create_clause is
>
> CONFIGURATION [IMMEDIATE| DEFERRED] USING partition_bound_spec
>
> and partition_bound_spec is:
>
> MODULUS integer | VALUES IN (expr [,...]) [, ....] | INTERVAL range_step
> FROM range_start TO range_end
ISTM That we should avoid new specific syntaxes when possible, and prefer
free keyword option style, like it is being discussed for some other
commands, because it reduces the impact on the parser.
That would suggest a more versatile partition_bound_spec which could look
like (<keyword> <constant-or-maybe-even-expr>[, …]):
For modulus, looks easy:
(MODULUS 8)
For interval, maybe something like:
(STEP ..., FROM/START ..., TO/END ...)
The key point is that for dynamic partitioning there would be no need for
boundaries, so that it could just set a point and an interval
(START/INIT/FROM??? ..., STEP ...)
For lists of values, probably it would make little sense to have dynamic
partitioning? Or maybe yes, if we could partition on a column
value/expression?! eg "MOD(id, 8)"??
What about pg_dump? Should it be able to regenerate the initial create?
> [4] https://wiki.postgresql.org/wiki/Declarative_partitioning_improvements
Good point, a wiki is better than a thread for that type of things. I'll
look at this page.
--
Fabien.