Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1krk3W-000368-BX for pgsql-hackers@arkaria.postgresql.org; Tue, 22 Dec 2020 15:58:34 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1krk3V-0005P7-4D for pgsql-hackers@arkaria.postgresql.org; Tue, 22 Dec 2020 15:58:33 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1krk3U-0005O5-QW for pgsql-hackers@lists.postgresql.org; Tue, 22 Dec 2020 15:58:32 +0000 Received: from mail-vs1-xe35.google.com ([2607:f8b0:4864:20::e35]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1krk3O-0004CF-6n for pgsql-hackers@lists.postgresql.org; Tue, 22 Dec 2020 15:58:31 +0000 Received: by mail-vs1-xe35.google.com with SMTP id b23so7245001vsp.9 for ; Tue, 22 Dec 2020 07:58:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=JGUNbTjZzb5/5spLPZMts7QTAYQUUaZcBIsjc07ZE/U=; b=trPXixwxBzy6JtWR7Ds+u1bMHIKLFDzgPTOuIo4CniRASq4YVsdDutRlYOylZ03B5m zra0dSgt3OR6HABwyPKGgRUoT4SRwE0jyOOFI9hENkc70Yzgp2ji+/v5nuVFYRNnUdS5 /HfGvF0hwrmHiXaRiTE7AW8uuabGewgQkDaMWTUFfiaTJt7bcoMYSMqfABjRDc95H7Nu PMu7IwC5994MAzVtSfNcv14mEnZDaBoi4JGWgjX7EINwpjnlWoaMP0UVO+auml869Fm4 t/UQJDeewV6+6aLJUvHFM1IB2ne2uUOqTf/FZn3UvzkLI9P4YucP8K96KRkmbHUu4cJE em1w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=JGUNbTjZzb5/5spLPZMts7QTAYQUUaZcBIsjc07ZE/U=; b=NJhpKvOvSijUaistGcK8WT9IM9PhMWHLhzEhFfsOOCy/PE+iWpZnWcUniDw878TVzo w+XUBPNZeHqf+VP+unqz9IGxdYguGqPM8A02UrDd9tVKcufGJTo1DDwz/hk+jRcIld4l hSMS8oIVn83+H6WfPpyH5yBLnR8NBvdAUpBCt483m98hLb9bHJQgz2axXu+DnB2UKhYV LRlSTqpSFxWm7ojA6csodtnmu7mi1ZndK8JDRv5LflHiHXl9iuVw2LrVsxu6dBwZRrxj N2CQrp/MnkqfocY8sGOqGiADq131AnGLJJiilZRjb/9Dm8u5q521VDhCos7A1n2JNcE3 bvvw== X-Gm-Message-State: AOAM532Puu7fp8mISJegRKVhiKwCnQQJJ31YnAQ6XqqfyyhBsU/7PCTz IDJL9gTJoGcFz6sJSi/yaXL4HOJDKvH0gCMw3/0= X-Google-Smtp-Source: ABdhPJw7UUkJvXwyxKFBJmhhHIsaMXJPVFm5zZMFOBWaVvSF7nm3edCJ73epS4J+7DoSdnxDalDAWV5pephnMzmmnhQ= X-Received: by 2002:a67:6b46:: with SMTP id g67mr15724835vsc.60.1608652705075; Tue, 22 Dec 2020 07:58:25 -0800 (PST) MIME-Version: 1.0 References: <7fec3abb-c663-c0d2-8452-a46141be6d4a@postgrespro.ru> <726c63e2-ef34-8113-f3cf-90e1646e4c2b@postgrespro.ru> <74a716a3-986d-c737-6217-6a3ffd488da3@postgrespro.ru> <20200924032738.GA28585@paquier.xyz> <37f1072a-16ec-8ce8-8044-1fcec85c8ed5@postgrespro.ru> <199124d5-e710-71a6-1836-4653cd668d96@postgrespro.ru> <8b1fce70861e2143cef9c7a69b740d61@postgrespro.ru> In-Reply-To: From: Pavel Borisov Date: Tue, 22 Dec 2020 19:58:13 +0400 Message-ID: Subject: Re: [PATCH] Automatic HASH and LIST partition creation To: Fabien COELHO Cc: Maxim Orlov , Anastasia Lubennikova , Rahila Syed , Michael Paquier , PostgreSQL Hackers , Justin Pryzby , Robert Haas , Amul Sul Content-Type: multipart/alternative; boundary="0000000000000d96ea05b70fa54b" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk --0000000000000d96ea05b70fa54b Content-Type: text/plain; charset="UTF-8" > > 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. > Thank you very much, Fabien. It is clear enough. BTW could you tell me a couple of words about pros and cons of c-code syntax parsing comparing to parsing using gram.y trees? I think both are possible but my predisposition was that we'd better use the later if possible. Best regards, Pavel Borisov > --0000000000000d96ea05b70fa54b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


Why? We could accept anything in the list? i.e.:

=C2=A0 =C2=A0 (ident =3D? value[, ident =3D? 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.<= br>
the ident is a keyword that can be interpreted later on, not a "reserv= ed
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 yo= ur
> proposal.

Yep. I think that it was not so good a design choice from a
language/extensibility perspective.
Thank you very much, Fabien. It is clear enough.
BT= W could you tell me a couple of words about pros and cons of c-code syntax = parsing comparing to parsing using gram.y trees? I think both are possible = but my predisposition was that we'd better use the later if possible.

Best regards,
Pavel Borisov
--0000000000000d96ea05b70fa54b--