adelapena commented on PR #1892: URL: https://github.com/apache/cassandra/pull/1892#issuecomment-1358045881
Thanks for the review. I have rebased the branch and tried to address the suggestions on an additional commit. CI: * https://app.circleci.com/pipelines/github/adelapena/cassandra/2531/workflows/0c22bed2-ed42-4d96-985d-df23a36d846f * https://app.circleci.com/pipelines/github/adelapena/cassandra/2531/workflows/d78e875e-ec27-4a93-935d-1f9233065e19 As discussed on Slack, the proposed functions are taken into account in the `ResultSet` metadata when the functions are used as regular function calls in a `SELECT` query. That metadata will be comprised by functions calls with the adequate type. Thus, using functions that return a data type different to their input shouldn't be a problem when directly using the functions in queries, like for example `SELECT mask_hash(v) FROM t`. In that example, the `ResultSet` metadata will contain a column named `mask_hash(v)` of type `blob`. That shouldn't surprise the user running the query. However, we should take those return types into account during CASSANDRA-18068. On that ticket we will allow to attach the utility masking functions to table columns on `CREATE/ALTER TABLE`. That can be problematic because in that case the user query is not explicitly invoking the function, and the name and type of the column don't change on the `ResultSet`. Probably we will need to just forbid attaching type-altering masking functions to column definitions on `CREATE/ALTER TABLE`. We could also forbid them by default but have a config property that allows that kind of mapping, if we see any value to it. However, there doesn't seem to be a reason to forbid the explicit use of those functions on regular `SELECT` queries. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
