feat: impl the basic string_agg function

[haohuaijin]

Which issue does this PR close?

part of #7910

Rationale for this change

add a new aggregate function string_agg

What changes are included in this PR?

Implement the basic string_agg function, which currently does not support distinct and order by clauses.
Support for distinct and order by will be added in future pr.

Are these changes tested?

Are there any user-facing changes?

[haohuaijin]

In postgresql, select string_agg('a', NULL) return a
but in duckdb, select string_agg('a', NULL) return NULL
I implemented it according to postgresql.

[haohuaijin]

I ported these tests over from duckdb.

[alamb]

cc @universalmind303 -- do you have time to help review this PR?

[2010YOUY01]

Thank you! The implementation looks good to me, one minor suggestion is to add some empty string cases to sqllogictest like select string_agg('', '|'), string_agg('a', '');

Also adopting test cases from mature systems like Postgres/Duckdb is a really good idea 👍🏼 , we should encourage contributors to do so when adding new functions

[haohuaijin]

select string_agg('', '|'), string_agg('a', '');

Thanks for this example @2010YOUY01 , I found a bug in handling empty strings and nulls, which has now been fixed and added additional tests.

[haohuaijin]

the ci break maybe related to #8169

[ozankabak]

@haohuaijin, indeed seems like it. We will fix promptly

[haohuaijin]

@ozankabak I've submitted a PR to try to fix it #8186

[ozankabak]

Thank you for the hotfix, for some reason we didn't realize the tweak needed to accommodate #8034

[ozankabak]

I will approve the hotfix once CI passes

[haohuaijin]

PTAL @alamb

[alamb]

Thanks @haohuaijin this looks good to me -- I have a few small suggestions, but overall I think it looks good.

One thing I thought of was is I think this function will be non deterministic when aggregating without an ORDER BY -- specifically since the aggregate can see the inputs in any order when doing a multi-phase repartitioned group by.

I don't think we need to fix this now, but we should probably file a ticket to fix it

Thanks again

[alamb]

using i64 means this will always take LargeStringArray, right? Shouldn't this use i32 for StringArray and i64 for LargeStringArray? However, the tests seem to cover this so this one looks good to me

[haohuaijin]

I do some cast like in sum i32 -> i64, so when we input a StringArray, cast it to a LargeStringArray.

[alamb]

Suggested change

	SELECT 'text1'::varchar(1000) as my_column union all
	SELECT 'text1'::varchar(1000) as my_column union all
	SELECT 'text1'::varchar(1000) as my_column
	SELECT 'text1'::varchar(1000) as my_column union all
	SELECT 'text2'::varchar(1000) as my_column union all
	SELECT 'text3'::varchar(1000) as my_column

[haohuaijin]

with out order by inside string_agg, the result is non deterministic, so I keep text1.

[alamb]

That makes sense -- thank you

[haohuaijin]

we should probably file a ticket to fix it

track in #8260

[alamb]

Thanks @haohuaijin@universalmind303 and @2010YOUY01