Re: extensible options syntax for replication parser?

From: Fujii Masao <masao(dot)fujii(at)oss(dot)nttdata(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>, tushar <tushar(dot)ahuja(at)enterprisedb(dot)com>
Cc: Sergei Kornilov <sk(at)zsrv(dot)org>, Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: extensible options syntax for replication parser?
Date: 2021-09-24 04:01:18
Message-ID: 38533959-ab69-7d47-6f3a-eb900f2fbc3f@oss.nttdata.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2021/09/24 0:05, Robert Haas wrote:
> On Thu, Sep 23, 2021 at 2:55 AM tushar <tushar(dot)ahuja(at)enterprisedb(dot)com> wrote:
>> l checked and look like the issue is still not fixed against v7-* patches -
>>
>> postgres=# create subscription test CONNECTION 'host=127.0.0.1 user=edb dbname=postgres' PUBLICATION p with (create_slot = true);
>> ERROR: could not create replication slot "test": ERROR: syntax error
>
> Thanks. Looks like that version had some stupid mistakes. Here's a new one.

- <indexterm><primary>BASE_BACKUP</primary></indexterm>
+ <term><literal>BASE_BACKUP</literal> [ ( <replaceable class="parameter">option</replaceable> [, ...] ) ]

You seem to accidentally remove the index term for BASE_BACKUP.

+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?

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

Regards,

--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Greg Nancarrow 2021-09-24 04:38:10 Re: Skipping logical replication transactions on subscriber side
Previous Message Pavel Stehule 2021-09-24 03:59:54 Re: proposal: possibility to read dumped table's name from file