feat: support byte string literal in bq

[togami2864]

https://cloud.google.com/bigquery/docs/reference/standard-sql/lexical#string_and_bytes_literals

[coveralls]

Pull Request Test Coverage Report for Build 4214280739

• 29 of 34 (85.29%) changed or added relevant lines in 4 files are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage decreased (-0.002%) to 86.14%

---

Changes Missing Coverage	Covered Lines	Changed/Added Lines	%
src/parser.rs	4	6	66.67%
src/tokenizer.rs	11	14	78.57%

Totals
Change from base Build 4206765944:	-0.002%
Covered Lines:	13400
Relevant Lines:	15556

---

💛 - Coveralls

[AugustoFKL]

Left a comment.

One thing that bothers me is that you didn't test the 'b' literal. Please add some tests for it, if possible.

[AugustoFKL]

This is something related to BigQuery, as I couldn't find this on MySQL. Maybe we could make this dialect-specific so we avoid permissive syntax on other dialects...?

@alamb

[togami2864]

How about using dialect_of! like this.

b @ 'B' | b @ 'b' if dialect_of!(self is BigQueryDialect | GenericDialect) => { ..

[AugustoFKL]

Seems reasonable

[togami2864]

We can only choose between 'b' or 'B' when converting AST into string result for test. So, I didn't test it. Is there any good approach??

[AugustoFKL]

@togami2864 wym?

I'd test it by using 'verified statement' usually... Considering the select, you put as an example:

SELECT B'abc', B"abc"

The resulting query is equals to the input? If so, use the verified_stmt method to show that. This way we can assure how the output is based on the input

[alamb]

This PR is looking good to me - thank you for the work @togami2864 and your help getting this ready for merge @AugustoFKL

It looks like CI is failing (though that may be resolved with a merge from main to get the clippy fixes). Is there anything else we are waiting on?

[togami2864]

All tasks are done. There is nothing else we waiting on.

[alamb]

Looks good to me -- thank you @togami2864 and @AugustoFKL