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.
