On 30.09.2020 22:58, Rahila Syed wrote:
Hi Anastasia,
I tested the syntax with some basic commands and it works fine, regression tests also pass.
Thank you for your review.
Couple of comments:
1. The syntax used omits the { IMMEDIATE | DEFERRED} keywords suggested in
the earlier discussions. I think it is intuitive to include IMMEDIATE with the current implementation
so that the syntax can be extended with a DEFERRED clause in future for dynamic partitions.
CREATE TABLE tbl_lst (i int) PARTITION BY LIST (i)
CONFIGURATION (values in (1, 2), (3, 4) DEFAULT PARTITION tbl_default);
After some consideration, I decided that we don't actually need to introduce IMMEDIATE | DEFERRED keyword. For hash and list partitions it will always be immediate, as the number of partitions cannot change after we initially set it. For range partitions, on the contrary, it doesn't make much sense to make partitions immediately, because in many use-cases one bound will be open.
2. One suggestion for generation of partition names is to append a unique id to
avoid conflicts.
Can you please give an example of such a conflict? I agree that current naming scheme is far from perfect, but I think that 'tablename'_partnum provides unique name for each partition.
3. Probably, here you mean to write list and hash instead of range and list as
per the current state.
<para>
Range and list partitioning also support automatic creation of partitions
with an optional <literal>CONFIGURATION</literal> clause.
</para>
4. Typo in default_part_name
+VALUES IN ( <replaceable class="parameter">partition_bound_expr</replaceable> [, ...] ), [( <replaceable class="parameter">partition_bound_expr</replaceable> [, ...] )] [, ...] [DEFAULT PARTITION <replaceable class="parameter">defailt_part_name</replaceable>]
+MODULUS <replaceable class="parameter">numeric_literal</replaceable>
Yes, you're right. I will fix these typos in next version of the patch.
--
Anastasia Lubennikova
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company