ApplyVSchemaDDL: escape Sequence names when writing the VSchema

[hkdsun]

Description

We use ALTER VSCHEMA ... ADD AUTO_INCREMENT ... statements to provision new sharded tables with their Sequence table references, however we ran into a bug because our sequence tables are stored in keyspaces that contain dashes (e.g. `app-name-global`.sequence_table).

The issue is that the ApplyVSchemaDDL function does not escape the value of the Sequence field below even though it's capable of parsing user input correctly:

		table.AutoIncrement = &vschemapb.AutoIncrement{
			Column:   alterVschema.AutoIncSpec.Column.String(),
			Sequence: sequenceFqn,
		}

Not surprising, since we're going through a cycle of parsing user input (from a SQL statment) and then trying to write something out to the VSchema's Table.AutoIncrement.Sequence field with the (new-ish?) understanding that it will be parsed using sqlparser again. As the VSchema docs mention, "If necessary, the reference to the sequence table lookup.user_seq can be escaped using backticks."

We would really love to have this be backported and have a v14.0.5 minor version be released with this fix.

Related Issue(s)

Checklist

• "Backport to:" labels have been added if this change should be back-ported
• Tests were added or are not required
• Did the new or modified tests pass consistently locally and on the CI
• Documentation was added or is not required

Deployment Notes

There should be no functional change in correct existing behaviour. The failing case will be fixed by the changes.

[vitess-bot]

Review Checklist

Hello reviewers! 👋 Please follow this checklist when reviewing this Pull Request.

General

• Ensure that the Pull Request has a descriptive title.
• If this is a change that users need to know about, please apply the release notes (needs details) label so that merging is blocked unless the summary release notes document is included.
• If a test is added or modified, there should be a documentation on top of the test to explain what the expected behavior is what the test does.

If a new flag is being introduced:

• Is it really necessary to add this flag?
• Flag names should be clear and intuitive (as far as possible)
• Help text should be descriptive.
• Flag names should use dashes (-) as word separators rather than underscores (_).

If a workflow is added or modified:

• Each item in Jobs should be named in order to mark it as required.
• If the workflow should be required, the maintainer team should be notified.

Bug fixes

• There should be at least one unit or end-to-end test.
• The Pull Request description should include a link to an issue that describes the bug.

Non-trivial changes

• There should be some code comments as to why things are implemented the way they are.

New/Existing features

• Should be documented, either by modifying the existing documentation or creating new documentation.
• New features should have a link to a feature request issue or an RFC that documents the use cases, corner cases and test cases.

Backward compatibility

• Protobuf changes should be wire-compatible.
• Changes to _vt tables and RPCs need to be backward compatible.
• vtctl command output order should be stable and awk-able.
• RPC changes should be compatible with vitess-operator
• If a flag is removed, then it should also be removed from VTop, if used there.

[deepthi]

@vitessio/query-serving please review

[hkdsun]

I've just rewritten the branch to solve this more elegantly.

One might think "this should have always been written as such" 😄

Could I please get a review? And any word on whether this could be backported? Our team at Shopify would have to otherwise plan a forked release fairly soon.

Thanks everyone

[deepthi]

Elegant is correct 😄
LGTM, and I think we can backport.
We'll wait to get at least 1 more approval from the query-serving team.

[systay]

nice stuff