fix(sqlparser): typed string must be single quoted

[xiangjinwu]

I hereby agree to the terms of the RisingWave Labs, Inc. Contributor License Agreement.

What's changed and what's your intention?

See #17461. Somehow a user wrote the invalid SQL Date t::date but it was interpreted by our sqlparser as (Date 't')::date and resulting in evaluation error.

The root cause is upstream apache/datafusion-sqlparser-rs#235 support of HiveSQL where an unquoted identifier can be treated as a literal string value. It is never the case for PostgreSQL.

After the fix, we report the following error message:

dev=> select date t::date from generate_series('2024-01-01 00:00:00+00'::timestamptz, now(), interval '1 month') as s(t);
ERROR:  Failed to run the query

Caused by:
  sql parser error: expected end of statement, found: ::
LINE 1: select date t::date from generate_series('2024-01-01 00:00:00+00'::timestamptz, now(), interval '1 month') as s(t);
                     ^

which is similar to PostgreSQL:

test=# select date t::date from generate_series('2024-01-01 00:00:00+00'::timestamptz, now(), interval '1 month') as s(t);
ERROR:  syntax error at or near "::"
LINE 1: select date t::date from generate_series('2024-01-01 00:00:0...
                     ^

Checklist

• I have written necessary rustdoc comments
• I have added necessary unit tests and integration tests
• I have added test labels as necessary. See details.
• I have added fuzzing tests or opened an issue to track them. (Optional, recommended for new SQL features Sqlsmith: Sql feature generation #7934).
• My PR contains breaking changes. (If it deprecates some features, please create a tracking issue to remove them in the future).
• All checks passed in ./risedev check (or alias, ./risedev c)
• My PR changes performance-critical code. (Please run macro/micro-benchmarks and show the results.)

• My PR contains critical fixes that are necessary to be merged into the latest release. (Please check out the details)

Documentation

• My PR needs documentation updates. (Please use the Release note section below to summarize the impact on users)

Release note

If this PR includes changes that directly affect users or other significant modifications relevant to the community, kindly draft a release note to provide a concise summary of these changes. Please prioritize highlighting the impact these changes will have on users.

[xiangjinwu]

Strictly speaking this fix is a breaking change. But it was wrong syntax and our documentation has been using single quotes correctly. The impact shall be negligible.

[xiangjinwu]

risingwave/e2e_test/udf/external_udf.slt

Line 8 in 18f9980

create function int_42() returns int as int_42 using link 'http://localhost:8815';

This as int_42 has been mis-parsed as SingleQuotedDef

risingwave/src/sqlparser/src/ast/mod.rs

Lines 2885 to 2890 in 18f9980

	#[derive(Debug, Clone, PartialEq, PartialOrd, Eq, Ord, Hash)]
	#[cfg_attr(feature = "serde", derive(Serialize, Deserialize))]
	pub enum FunctionDefinition {
	SingleQuotedDef(String),
	DoubleDollarDef(String),
	}

cc @wangrunji0408 Shall we introduce a new variant for (unquoted or double quoted) identifier?

[stdrc]

LGTM!

[wangrunji0408]

cc @wangrunji0408 Shall we introduce a new variant for (unquoted or double quoted) identifier?

added

Actually I think the string after as should be quoted. But for compatibility, it's better not to deprecate the support for unquoted identifier.

[xiangjinwu]

When I said (unquoted or double quoted) identifier I was thinking of .real_value() but now I realize .value has better backward compatibility:

When the SQL to parse is as camelCase, the old behavior gets camelCase but the identifier's real_value is camelcase. Although as "camelCase" is a case-sensitive identifier, I agree it is better to encourage as 'camelCase' if breaking change is inevitable.