support more type in postgres-extended

[ZENOTME]

This PR does two things:

1. support INTERVAL && TIMESTAMPTZ type in postgres-extended
2. refactor run() in postgres-extended: use a macro to generate process

[xxchan]

Why to use macro here? How is it simplier than before?

[ZENOTME]

reduce duplication like

Type::NUMERIC => {
    single_process!(row, output, idx, Decimal);
}
Type::TIMESTAMP => {
    single_process!(row, output, idx, NaiveDateTime);
}
Type::DATE => {
    single_process!(row, output, idx, NaiveDate);
}
...

[xxchan]

IMO such level of duplication is fine. Macro seems an overkill and hurts readability.

[xxchan]

BTW, why would you want to format the time results instead of keeping it as-is? What's the motivation? 👀

[ZENOTME]

BTW, why would you want to format the time results instead of keeping it as-is? What's the motivation? 👀

Because for the time type(such as INTERVAL), there is more than one string format representing the same value.
Such as '31 days' and '1 mon', they have the same semantics.
So the easiest way to compare these is to declare a fixed format.

More detail: #93

[xxchan]

there is more than one string format representing the same value

But maybe some users do want to depend on such behavior, and the db implementation want to respect the behavior? (😅

[xxchan]

BTW this will make postgres and postgres-extended not compatible. i.e., some test cases will pass one but fail the another. Is this what you expect?

[ZENOTME]

BTW this will make postgres and postgres-extended not compatible. i.e., some test cases will pass one but fail the another. Is this what you expect?

In risingwave, Postgres and Postgres-extended have different e2e tests now. So I think it's acceptable to make it not compatible now. After introducing the custom comparator, we can make it compatible I think. 🤔

[xxchan]

After introducing the custom comparator, we can make it compatible I think.

Actually it's still not 100% "compatible". Specifically if it can pass postgres-extended, it can fail postgres #93 (comment) 🤔

Maybe we need to completely switch to postgres-extended?

[ZENOTME]

Maybe we need to completely switch to postgres-extended?

We can't completely switch to postgres-extended because there are some type can't support in postgres-extended such as multi-dimensional array and struct.

[skyzh]

Originally I think of rewriting all of SQL queries that output date time column, so that they won't directly appear in sqllogictest. e.g, to_char(interval '15h 2m 12s', 'HH24:MI:SS'). Anyway, this approach also LGTM.

[skyzh]

Ping me when you're ready to merge and release a new version.

[ZENOTME]

Originally I think of rewriting all of SQL queries that output date time column, so that they won't directly appear in sqllogictest. e.g, to_char(interval '15h 2m 12s', 'HH24:MI:SS'). Anyway, this approach also LGTM.

I'm aware of actually we can use (...)::varchar eg: (interval '15h 2m 12s')::varchar to convert any type into varchar type so that we can compare it with string.

[ZENOTME]

I'm aware of actually we can use (...)::varchar eg: (interval '15h 2m 12s')::varchar to convert any type into varchar type so that we can compare it with string.

I use this way to convert theinterval timestamptztype to string. So now for these two types, Postgres and Postgres-extended are compatible. And I also do other additional work:

• support array type of the supported single type
• add a test file

@skyzh @xxchan

[skyzh]

LGTM, merging now.