feat: Add implicit casting to TypeSignature::String

[jonathanc-n]

Which issue does this PR close?

Closes #.

Rationale for this change

#13402 #13394 were running into some problems with implicit casting due to TypeSignature::String not dealing with implicit casting properly

What changes are included in this PR?

Added implicit casting to TypeSignature::String

Are these changes tested?

Yes

Are there any user-facing changes?

[Omega359]

Please remove the changes to regexp_match as that change adds in support for utf8view which breaks that function (see ci output). It's a much larger issue than those changes. See #11911 (comment) for some details.

[jonathanc-n]

Will fix this tommorow.

[jayzhan211]

DuckDB doesn't allow this query 🤔
Numeric string casting is quite confusing to me

D SELECT ltrim(12345, '1');
Binder Error: No function matches the given name and argument types 'ltrim(INTEGER_LITERAL, STRING_LITERAL)'. You might need to add explicit type casts.
	Candidate functions:
	ltrim(VARCHAR) -> VARCHAR
	ltrim(VARCHAR, VARCHAR) -> VARCHAR

LINE 1: SELECT ltrim(12345, '1');

Same with postgres

postgres=# SELECT ltrim(12345, '1');
ERROR:  function ltrim(integer, unknown) does not exist
LINE 1: SELECT ltrim(12345, '1');
               ^
HINT:  No function matches the given name and argument types. You might need to add explicit type casts.

[jayzhan211]

Mark this as draft as it is not ready for review

[jonathanc-n]

@alamb @jayzhan211 I'm a bit confused with this pr, are we looking to support implicit casting with TypeSignature or not? As can be seen above, this behaviour seems to have been deprecated in DuckDB.

[jayzhan211]

this behaviour seems to have been deprecated in DuckDB.

I think we still prefer the actual result in Postgres and DuckDB

[jonathanc-n]

@jayzhan211 So should this PR be closed? Since there is no need for implicit casting in TypeSignature::String? I just worked on this because of your comment on implicit casting in #13301

[jayzhan211]

@jayzhan211 So should this PR be closed? Since there is no need for implicit casting in TypeSignature::String? I just worked on this because of your comment on implicit casting in #13301

Sure.

[Omega359]

I don't agree with the decision to not support implicit coercion to string for function arguments.

Firstly, it's a regression from currently supported features and will break things for users, myself included.

Secondly Postgresql's requirement for explicit casting for so many things imho is one of it's most annoying 'features' and is generally not required by just about every other database out there. The reasoning given for the DuckDB decision was nothing to do with functions and everything to do with casting issues with general sql and comparisons which I tend to agree with. See the PR for details.

select length(42:VARCHAR);

should not be required.

select length(42);

should just work.

[alamb]

Firstly, it's a regression from currently supported features and will break things for users, myself included.

For this reason alone I agree , and it would definitely fall into the category of implicit semantic changes causing troubles described on

• [DISCUSSION] Making it easier to use DataFusion (lessons from GlareDB) #13525)

I don't fully understand the current state -- is there a regression between 43 and 44 (not yet released)? If so, is it tracked with a ticket?

[Omega359]

The regression I think was in 43 but I am not 100% sure. I just built 42 off the tag and ran it in docker:

root@f93d03a93bc1:/apache_datafusion# docker run --rm -it datafusion-cli_42
DataFusion CLI v42.2.0
> select ascii(42);
+------------------+
| ascii(Int64(42)) |
+------------------+
| 52               |
+------------------+
1 row(s) fetched. 
Elapsed 0.001 seconds.

The slt test I just added in main:

External error: query failed: DataFusion error: Error during planning: Error during planning: The signature expected NativeType::String but received NativeType::Int64 No function matches the given name and argument types 'ascii(Int64)'. You might need to add explicit type casts.
        Candidate functions:
        ascii(String(1))
[SQL] SELECT ascii(2)
at test_files/expr.slt:322

I suspect any function switched in #12751 will no longer work with any type coercion.

Edit: just verified the above sql works with DF 41 as well.