Add a native type manager

[pdabre12]

Description

With the introduction of the presto-native-execution module, Presto now has forked the execution engine into a separate process. This allows for the execution engine to be written in C++ and to be more efficient than the Java execution engine. However, this also means that the execution engine code is now entirely separate from the coordinator code, and that the types supported by the coordinator might not necessarily be supported by the execution engine.

This change adds a new native type manager which allows the types supported by the C++ engine to be known to the Java coordinator.

For more context: RFC-0003

Test Plan

Unit and end-to-end tests. More comprehensive end-to-end tests will be written in the future.

Contributor checklist

• Please make sure your submission complies with our contributing guide, in particular code style and commit standards.
• PR description addresses the issue accurately and concisely. If the change is non-trivial, a GitHub Issue is referenced.
• Documented new properties (with its default value), SQL syntax, functions, or other functionality.
• If release notes are required, they follow the release notes guidelines.
• Adequate tests were added if applicable.
• CI passed.

Release Notes

Please follow release notes guidelines and fill in the release notes below.

== RELEASE NOTES ==

Prestissimo (Native Execution) Changes
* Add a native type manager

[auden-woolfson]

LGTM

Addressed the comments

[pdabre12]

@ZacBlanco Do you wanna take a look?

[aditi-pandit]

Trying to reduce the impact of this hack. What happens if we remove CHAR from this condition and fail all the queries with it ?

[pdabre12]

Done, removed CHAR.

[pdabre12]

@rschlussel
Can you please have another look?
Native engine shouldn't allow creating tables with char column.
Whenever the sidecar plugin is enabled, any queries on the older tables constructed with char column will fail.
Is it safe to do so in your production environment?

[libianoss]

@rschlussel can you help to review this PR?Thanks.

[rschlussel]

@rschlussel Can you please have another look? Native engine shouldn't allow creating tables with char column. Whenever the sidecar plugin is enabled, any queries on the older tables constructed with char column will fail. Is it safe to do so in your production environment?

i don't think i understand what this means. Why doesn't native engine allow creating tables with char column? Currently without sidecar, what happens if someone runs a query on a table with a char column?

[pdabre12]

@rschlussel Can you please have another look? Native engine shouldn't allow creating tables with char column. Whenever the sidecar plugin is enabled, any queries on the older tables constructed with char column will fail. Is it safe to do so in your production environment?

i don't think i understand what this means. Why doesn't native engine allow creating tables with char column? Currently without sidecar, what happens if someone runs a query on a table with a char column?

As of now, the native engine allows creating tables with char column and queries on a table with a char column should succeed. But with sidecar enabled, we are getting a list of supported types by the native engine and CHAR is not a part of it. As a result, if you have old tables created with the underlying column type as char and enable the sidecar, the queries on that table will fail.

[rschlussel]

@rschlussel Can you please have another look? Native engine shouldn't allow creating tables with char column. Whenever the sidecar plugin is enabled, any queries on the older tables constructed with char column will fail. Is it safe to do so in your production environment?

i don't think i understand what this means. Why doesn't native engine allow creating tables with char column? Currently without sidecar, what happens if someone runs a query on a table with a char column?

As of now, the native engine allows creating tables with char column and queries on a table with a char column should succeed. But with sidecar enabled, we are getting a list of supported types by the native engine and CHAR is not a part of it. As a result, if you have old tables created with the underlying column type as char and enable the sidecar, the queries on that table will fail.

if currently we can run queries on char columns, then why is it not supported?

[pdabre12]

@rschlussel Can you please have another look? Native engine shouldn't allow creating tables with char column. Whenever the sidecar plugin is enabled, any queries on the older tables constructed with char column will fail. Is it safe to do so in your production environment?

i don't think i understand what this means. Why doesn't native engine allow creating tables with char column? Currently without sidecar, what happens if someone runs a query on a table with a char column?

As of now, the native engine allows creating tables with char column and queries on a table with a char column should succeed. But with sidecar enabled, we are getting a list of supported types by the native engine and CHAR is not a part of it. As a result, if you have old tables created with the underlying column type as char and enable the sidecar, the queries on that table will fail.

if currently we can run queries on char columns, then why is it not supported?

I am not really sure what happens under the hood right now when you create a table with char columns in a native cluster. The native engine does not understand char type, maybe it gets casted to a varchar( not sure) ? cc: @aditi-pandit.
But with this change, we only report the types supported by the native engine to the coordinator and as of now char is not one of them, so the queries would fail. This isn't an exclusive case for the char type but all the older and newer tables/queries with types not supported by the native engine would fail.

[rschlussel]

@gggrace14 showed me that we actually are failing now in the workers when you try to query a char column, so this change should be okay.

[aditi-pandit]

Thanks @pdabre12

[aditi-pandit]

@rschlussel Can you please have another look? Native engine shouldn't allow creating tables with char column. Whenever the sidecar plugin is enabled, any queries on the older tables constructed with char column will fail. Is it safe to do so in your production environment?

i don't think i understand what this means. Why doesn't native engine allow creating tables with char column? Currently without sidecar, what happens if someone runs a query on a table with a char column?

As of now, the native engine allows creating tables with char column and queries on a table with a char column should succeed. But with sidecar enabled, we are getting a list of supported types by the native engine and CHAR is not a part of it. As a result, if you have old tables created with the underlying column type as char and enable the sidecar, the queries on that table will fail.

if currently we can run queries on char columns, then why is it not supported?

I am not really sure what happens under the hood right now when you create a table with char columns in a native cluster. The native engine does not understand char type, maybe it gets casted to a varchar( not sure) ? cc: @aditi-pandit. But with this change, we only report the types supported by the native engine to the coordinator and as of now char is not one of them, so the queries would fail. This isn't an exclusive case for the char type but all the older and newer tables/queries with types not supported by the native engine would fail.

@rschlussel : Today C++ clusters would support CREATE TABLE with char columns (as that is purely at the co-ordinator), but SELECT from them would fail at the workers since the PrestoToVelox conversions would reject the CHAR column. With this change, CHAR would not be exposed as a type, so even CREATE TABLE with char columns would fail.