binder/expr: parse literal to expected type in frontend

[xiangjinwu]

Some types do not have a dedicated literal syntax (e.g. 1, true, interval '1' hour, array[]) and can only be created by casting from string, including date, timestamp, timestamptz, time and bytea.

This cast expr is actually unnecessary. We can parse it to a literal of this type directly, just like how we handles typed null below:

risingwave/src/frontend/src/expr/function_call.rs

Lines 118 to 132 in 68b0111

	if child.is_null() {
	Ok(Literal::new(None, target).into())
	} else if source == target {
	Ok(child)
	// Casting from unknown is allowed in all context. And PostgreSQL actually does the parsing
	// in frontend.
	} else if child.is_unknown() || cast_ok(&source, &target, allows) {
	Ok(Self {
	func_type: ExprType::Cast,
	return_type: target,
	inputs: vec![child],
	}
	.into())
	} else {
	Err(ErrorCode::BindError(format!(

Basically, if child.is_null() { Ok(Literal::new(None, target).into()) } can be replaced by a more general form:
if child.is_unknown() { Ok(Literal::new(_???_, target()).into()) }

The missing part should be refactored from how we cast from string to a target type, maybe DataType::parse(&self, v: &str, timezone: &str) -> ScalarImpl. We also need to pass session timezone into new_cast somehow ...

[xiangjinwu]

Implemented with some restrictions/simplifications:

• Session timezone is not passed in. So it only parses 2022-01-01 12:00:00+01:00 but not 2022-01-01 12:00:00 as timestamptz. The latter case is still handled in previous code path.
• Array and struct input are not parsed. These are rarely used in practice and enables less optimizations.
• Parsing errors (eg 'a'::int) are silently ignored and fallback to previous code path. In other words, new_cast remains reporting errors only about typing but not evaluation. This is due to some assumptions hold by the callers.