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
v1-0001-Flexible-options-for-BASE_BACKUP-and-CREATE_REPLI.patch
Description: Binary data
