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 →
-
Flexible options for CREATE_REPLICATION_SLOT.
- 0266e98c6b86 15.0 landed
-
Flexible options for BASE_BACKUP.
- 0ba281cb4bf9 15.0 landed
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