SQL SECURITY for the Alias engine

The experimental Alias table engine gives a table a second name, and reads go through to the target. With row policies as the isolation boundary, the question is whose policies apply to a read through the alias. As I reported it, an alias with no policy of its own dropped the target’s, which is DEFINER behaviour without the SET DEFINER gate a DEFINER view needs. I proposed reusing the SQL SECURITY INVOKER | DEFINER clause views have had since 24.2, defaulting to INVOKER, so the safe behaviour is the default and not a special case.

The access-check bug itself was handled separately: #114596, “Fix target access checks for the Alias engine”, merged on 2026-08-24, the day the request was filed, and a reviewer asked that the target’s policies always apply. The SQL SECURITY request is open, labelled feature, comp-rbac and external, with no comments and no pull request.

On 26.4 the clause is still a syntax error, and the engine needs allow_experimental_alias_table_engine = 1:

SET allow_experimental_alias_table_engine = 1;
CREATE TABLE t (x UInt8) ENGINE = Memory;
CREATE TABLE a2 SQL SECURITY INVOKER ENGINE = Alias(t);
-- Code: 62. DB::Exception: Syntax error ... (SQL)

I did not test row-policy behaviour on 26.4. If you combine Alias with row policies, test it on your version. For the same mechanism on views, see users, roles and settings profiles.