refer to #8781, convert the internal_err! in datetime_expression.rs to exec_err!

[Tangruilin]

Which issue does this PR close?

Closes #.

Rationale for this change

releateto #8781

What changes are included in this PR?

change the internal_err maroc in datetime_expression.ts to exec_err!

Are these changes tested?

no

Are there any user-facing changes?

no

[Tangruilin]

@Omega359
I submit a PR to change the internal_err to exec_err

you can review this patch

[Tangruilin]

internal_err: something that wasn't expected/anticipated by the implementation and that is most likely a bug (the error message even encourages users to open a bug report). I user should not be able to trigger this under normal circumstances. Note that I/O errors (or any error that happens due to external systems) do NOT fall under this category (there's an external error variant for that)

exec_err: a processing error that happens during execution, e.g. the user passed malformed arguments to a SQL method, opened a CSV file that is broken, tried to divide an integer by zero. these errors shouldn't happen for a "good" query + "good" data, but since both the query and the data can easily be broken or misaligned, these are common occurrences in ETL systems / databases.

[Omega359]

I am uncertain as to whether the unsupported data type errors should always be internal or exec. I think it may depend on the signature of the function. For example, from_unixtime is specified as having a signature of

BuiltinScalarFunction::FromUnixtime => {
                Signature::uniform(1, vec![Int64], self.volatility())
            }

so if that function got anything other than Int64 it would definitely be unexpected and thus I would think that internal_err might be appropriate there. However, to_timestamp(_xxx) methods are defined as

BuiltinScalarFunction::ToTimestamp
            | BuiltinScalarFunction::ToTimestampSeconds
            | BuiltinScalarFunction::ToTimestampMillis
            | BuiltinScalarFunction::ToTimestampMicros
            | BuiltinScalarFunction::ToTimestampNanos => {
                Signature::variadic_any(self.volatility())
            }

So it would be expected that the impl would have to handle and return unacceptable types (thus exec_err)

[Tangruilin]

I am uncertain as to whether the unsupported data type errors should always be internal or exec. I think it may depend on the signature of the function. For example, from_unixtime is specified as having a signature of

BuiltinScalarFunction::FromUnixtime => {
                Signature::uniform(1, vec![Int64], self.volatility())
            }

so if that function got anything other than Int64 it would definitely be unexpected and thus I would think that internal_err might be appropriate there. However, to_timestamp(_xxx) methods are defined as

BuiltinScalarFunction::ToTimestamp
            | BuiltinScalarFunction::ToTimestampSeconds
            | BuiltinScalarFunction::ToTimestampMillis
            | BuiltinScalarFunction::ToTimestampMicros
            | BuiltinScalarFunction::ToTimestampNanos => {
                Signature::variadic_any(self.volatility())
            }

So it would be expected that the impl would have to handle and return unacceptable types (thus exec_err)

May I need to tidy up them and modify this PR?

[comphead]

lgtm thanks @Tangruilin
Going fwd i'm thinking of giving available signatures for specific built in functions, instead of just complaining about params

[alamb]

Thank you @comphead and @Tangruilin