Re: [PATCH] Automatic HASH and LIST partition creation

I've realized one strange effect in current grammar parsing: if I do

CREATE TABLE foo (a int) PARTITION BY LIST (a) CONFIGURATION (a 1);
ERROR: unrecognized auto partition bound specification "a"

I consulted the patch code and realized that in fact, the patch considers
it the (invalid) HASH bounds (doesn't find a word 'modulus') unless it is
specified to be (still invalid) LIST. This is due to the fact that the
grammar parser is not context-aware and in the patch, we tried to avoid the
new parser keyword MODULUS. The effect is that inside a CONFIGURATION
parentheses in case of HASH bounds we don't have a single keyword for the
parser to determine it is really a HASH case.

It doesn't make the patch work wrongly, besides it checks the validity of
all types of bounds in the HASH case even when the partitioning is not
HASH. I find this slightly bogus. This is because the parser can not
determine the type of partitioning inside the configuration clause and this
makes adding new syntax (e.g. adding RANGE partitioning configuration
inside CONFIGURATION parentheses) complicated.

So I have one more syntax proposal: to have separate keywords
inside CONFIGURATION parentheses for each partitioning type.
E.g:
CREATE TABLE foo(a int) PARTITION BY LIST(a) CONFIGURATION (FOR VALUES IN
(1,2),(3,4) DEFAULT PARTITION foo_def);
CREATE TABLE foo(a int) PARTITION BY HASH(a) CONFIGURATION (FOR VALUES WITH
MODULUS 3);
CREATE TABLE foo(a int) PARTITION BY RAGE(a) CONFIGURATION (FOR VALUES FROM
1 TO 1000 INTERVAL 10 DEFAULT PARTITION foo_def);

This proposal is in accordance with the current syntax of declarative
partitioning: CREATE TABLE foo_1 PARTITION OF foo FOR VALUES ...

Some more facultative proposals incremental to the abovementioned:
1. Omit CONFIGURATION with/without parentheses. This makes syntax closer
to (non-automatic) declarative partitioning syntax but the clause
seems less legible (in my opinion).
2. Omit just FOR VALUES. This makes the clause short, but adds a difference
to (non-automatic) declarative partitioning syntax.

I'm planning also to add RANGE partitioning syntax to this in the future
and I will be happy if all three types of the syntax could come along
easily.
I very much appreciate your views on this especially regarding that
changes can be still made easily because the patch is not committed yet.

--
Best regards,
Pavel Borisov

Postgres Professional: http://postgrespro.com <http://www.postgrespro.com>