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.
DEFERRED clause refers to creating partitions on the fly, while the data is being inserted.
The number of partitions and partition bounds can be the same as specified initially
during partitioned table creation, but the actual creation of partitions can be deferred.
This seems like a potential extension to statically created partitions even in the case of
hash and list partitions, as it won't involve moving any existing data.
2. One suggestion for generation of partition names is to append a unique id to
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.
Sorry for not being clear earlier, I mean the partition name 'tablename_partnum' can conflict with any existing table name.
As per current impemetation, if I do the following it results in the table name conflict.
postgres=# create table tbl_test_5_1(i int);
CREATE TABLE
postgres=# CREATE TABLE tbl_test_5 (i int) PARTITION BY LIST((tbl_test_5)) CONFIGURATION (values in ('(1)'::tbl_test_5), ('(3)'::tbl_test_5) default partition tbl_default_5);
ERROR: relation "tbl_test_5_1" already exists
Thank you,
Rahila Syed