Re: extensible options syntax for replication parser?

Robert Haas <robertmhaas@gmail.com>

From: Robert Haas <robertmhaas@gmail.com>
To: Fujii Masao <masao.fujii@oss.nttdata.com>
Cc: tushar <tushar.ahuja@enterprisedb.com>, Sergei Kornilov <sk@zsrv.org>, Fabien COELHO <coelho@cri.ensmp.fr>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Date: 2021-09-24T16:55:00Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →
  1. Flexible options for CREATE_REPLICATION_SLOT.

  2. Flexible options for BASE_BACKUP.

On Fri, Sep 24, 2021 at 12:01 AM Fujii Masao
<masao.fujii@oss.nttdata.com> wrote:
> You seem to accidentally remove the index term for BASE_BACKUP.

Good catch.

> +ident_or_keyword:
> +                       IDENT                                                   { $$ = $1; }
>
> ident_or_keyword seems to be used only for generic options,
> but it includes the keywords for legacy options like "FAST".
> Isn't it better to remove the keywords for legacy options from
> ident_or_keyword?

I don't think so. I mean, if we do, then it's not really an
ident_or_keyword production any more, because it would only allow some
keywords, not all. Now if the keywords that are not included aren't
used as options anywhere then it won't matter, but it seems cleaner to
me to make the list complete.

> OTOH, the keywords for newly-introduced generic options like
> CHECKPOINT should be defined in repl_scanner.l and repl_gram.y?

One big advantage of this approach is that we don't need to make
changes to those files in order to add new options, so I feel like
that would be missing the point completely.

-- 
Robert Haas
EDB: http://www.enterprisedb.com