extensible options syntax for replication parser? - Mailing list pgsql-hackers

From Robert Haas
Subject extensible options syntax for replication parser?
Date
Msg-id CA+TgmobAczXDRO_Gr2euo_TxgzaH1JxbNxvFx=HYvBinefNH8Q@mail.gmail.com
Whole thread Raw
Responses Re: extensible options syntax for replication parser?
List pgsql-hackers
Hi,

It seems to me that we're making the same mistake with the replication
parser that we've made in various placesin the regular parser: using a
syntax for options that requires that every potential option be a
keyword, and every potential option requires modification of the
grammar. In particular, the syntax for the BASE_BACKUP command has
accreted a whole lot of cruft already and I think that trend is likely
to continue. I don't think that trying to keep people from adding
options is a good strategy, so instead I'd like to have a better way
to do it. Attached is v1 of a patch to refactor things so that parts
of the BASE_BACKUP and CREATE_REPLICATION_SLOT are replaced with a
flexible options syntax. There are some debatable decisions here, so
I'd be happy to get some feedback on whether to go further with this,
or less far, or maybe even just abandon the idea altogether. I doubt
the last one is the right course, though: ISTM something's got to be
done about the BASE_BACKUP case, at least.

This version of the patch does not include documentation, but
hopefully it's fairly clear from reading the code what it's all about.
If people agree with the basic approach, I'll write docs. The
intention is that we'd continue to support the existing syntax for the
existing options, but the client tools would be adjusted to use the
new syntax if the server's new enough, and any new options would be
supported only through the new syntax. At some point in the distant
future we could retire the old syntax, when we've stopped caring about
compatibility with pre-14 versions.

Thoughts?

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

Attachment

pgsql-hackers by date:

Previous
From: Jeff Davis
Date:
Subject: Re: Default setting for enable_hashagg_disk
Next
From: David Rowley
Date:
Subject: Re: Parallel Seq Scan vs kernel read ahead