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.
