HEllo.
>>> CREATE TABLE foo(a int) PARTITION BY LIST(a) CONFIGURATION (FOR VALUES
>> IN
>>> (1,2),(3,4) DEFAULT PARTITION foo_def);
>>
>> I would like to disagree with this syntactic approach because it would
>> very specific to each partition method. IMHO the syntax should be as
>> generic as possible. I'd suggest (probably again) a keyword/value list
>> which would allow to be quite adaptable without inducing any pressure on
>> the parser.
>>
> If I remember your proposal correctly it is something like
> CREATE TABLE foo(...) PARTITION BY HASH AUTOMATIC (MODULUS 10);
Yep, that would be the spirit.
> It is still possible but there are some caveats: 1. We'll need to add
> keyword MODULUS (and probably AUTOMATIC) to the parser's list.
Why? We could accept anything in the list? i.e.:
(ident =? value[, ident =? value]*)
> I don't against this but as far as I've heard there is some
> opposition among PG community against new keywords. Maybe I am wrong.
the ident is a keyword that can be interpreted later on, not a "reserved
keyword" from a parser perspective, which is the only real issue?
The parser does not need to know about it, only the command interpreter
which will have to interpret it. AUTOMATIC is a nice parser cue to
introduce such a ident-value list.
> 2. The existing syntax for declarative partitioning is different to your
> proposal.
Yep. I think that it was not so good a design choice from a
language/extensibility perspective.
> It is still not a big problem and your proposal makes query
> shorter for several words. I'd just like to see some consensus on the
> syntax. Now I must admit there are too many contradictions in opinions
> which make progress slow. Also I think it is important to have a really
> convenient syntaх.
> 2a Maybe we all who participated in the thread can vote for some variant?
> 2b Maybe the existing syntax for declarative partitioniong should be given
> some priority as it is already committed into CREATE TABLE ... PARTITION OF
> ... FOR VALUES IN.. etc.
> I'd be happy if everyone will join some version of the proposed syntaх in
> this thread and in the previous discussion [1]. If we have a variant with
> more than one supporter, sure we can develop patch based on it.
> Thank you very much
> and Merry Christmas!
>
> [1]
> https://www.postgresql.org/message-id/flat/alpine.DEB.2.21.1907150711080.22273%40lancre
>
>
--
Fabien.