IMPALA-14875: Make a Preconditions check case-insensitive in authorize() In IMPALA-14507, we slightly revised a Preconditions check that requires each column-level privilege request has at least one respective table-level privilege request. However, we found that this introduced a regression due to which the check would fail in the local catalog mode if the name of the target table in the CREATE TABLE AS SELECT statement contains uppercase letters. For instance, a query like the following would fail in the local catalog mode. create table alltypes_A as select int_col from functional.alltypes; One root cause of this was that during the registration of the column-level INSERT privilege in InsertStmt#analyze(), table_.getTableName().getTbl() would still contain uppercase letters in the local catalog mode. As a result, during the Preconditions check in BaseAuthorizationChecker#authorize(), the key of the same table in the map from table name to the associated table-level privilege requests did not match that in the map from table name to the associated column-level privilege requests, causing the check to fail. In our example, the key of the target table in the former map would end with "alltypes_a", whereas that of the latter map ended with "alltypes_A". To fix the issue, this patch lowercases the table name when constructing the 2 maps above. On a related note, the issue only affected the CTAS statement but not the INSERT statement. This is because during the analysis of the CTAS statement in the local catalog mode, we create a temporary target table 'table_' such that table_.getTableName().getTbl() could still contain uppercase letters and then call InsertStmt#analyze() with 'table_' being the target table. For the INSERT statement, the name of the target table is already lowercased for both catalog modes. Testing: - Added test cases to verify that a CTAS statement could pass the Preconditions check even though the name of target table has capital letters. Change-Id: Idfae24a7de8da683bc0bf28a947188ab96481301 Reviewed-on: http://gerrit.cloudera.org:8080/24165 Reviewed-by: Yida Wu <wydbaggio000@gmail.com> Tested-by: Impala Public Jenkins <impala-public-jenkins@cloudera.com> Reviewed-by: Michael Smith <michael.smith@cloudera.com>
Lightning-fast, distributed SQL queries for petabytes of data stored in open data and table formats.
Impala is a modern, massively-distributed, massively-parallel, C++ query engine that lets you analyze, transform and combine data from a variety of data sources:
The fastest way to try out Impala is a quickstart Docker container. You can try out running queries and processing data sets in Impala on a single machine without installing dependencies. It can automatically load test data sets into Apache Kudu and Apache Parquet formats and you can start playing around with Apache Impala SQL within minutes.
To learn more about Impala as a user or administrator, or to try Impala, please visit the Impala homepage. Detailed documentation for administrators and users is available at Apache Impala documentation.
If you are interested in contributing to Impala as a developer, or learning more about Impala's internals and architecture, visit the Impala wiki.
Impala only supports Linux at the moment. Impala supports x86_64 and has experimental support for arm64 (as of Impala 4.0). Impala Requirements contains more detailed information on the minimum CPU requirements.
Impala runs on Linux systems only. The supported distros are
Other systems, e.g. SLES12, may also be supported but are not tested by the community.
This distribution uses cryptographic software and may be subject to export controls. Please refer to EXPORT_CONTROL.md for more information.
See Impala's developer documentation to get started.
Detailed build notes has some detailed information on the project layout and build.