Re: [PATCH] Automatic HASH and LIST partition creation - Mailing list pgsql-hackers

On 2020-12-18 21:54, Pavel Borisov wrote:
> 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 [1]
> 
> 
> Links:
> ------
> [1] http://www.postgrespro.com

In my view, next expressions are the golden ground here. On one hand, 
not far from the original
non-automatic declarative partitioning syntax syntax, on the other hand, 
omit CONFIGURATION
key-word (which is redundant here in terms of gram parsing) makes this 
expressions less apprehensible for the human.

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);

In addition to that, adding RANGE PARTITION would be much simpler since 
we would have specific "branches" in gram instead of using 
context-sensitive grammar and dealing with it in c-code.
---
Best regards,
Maxim Orlov.