Documentation disagrees with behavior of ALTER EVENT TRIGGER

The documentation for ALTER EVENT TRIGGER claims "You must be superuser to alter an event trigger" which is manifestly false, as shown below:

+CREATE ROLE evt_first_owner SUPERUSER;
+CREATE ROLE evt_second_owner SUPERUSER;
+SET SESSION AUTHORIZATION evt_first_owner;
+CREATE OR REPLACE FUNCTION evt_test_func()
+RETURNS event_trigger AS $$
+BEGIN
+RAISE NOTICE 'event_trigger called with tag %', tg_tag;
+END;
+$$ LANGUAGE plpgsql;
+CREATE EVENT TRIGGER evt_test_trigger ON ddl_command_start
+ EXECUTE PROCEDURE evt_test_func();
+RESET SESSION AUTHORIZATION;
+ALTER ROLE evt_first_owner NOSUPERUSER;
+SET SESSION AUTHORIZATION evt_first_owner;
+ALTER EVENT TRIGGER evt_test_trigger DISABLE;
+ALTER EVENT TRIGGER evt_test_trigger ENABLE;
+ALTER EVENT TRIGGER evt_test_trigger ENABLE REPLICA;
+ALTER EVENT TRIGGER evt_test_trigger ENABLE ALWAYS;
+ALTER EVENT TRIGGER evt_test_trigger RENAME TO evt_new_name;
+RESET SESSION AUTHORIZATION;
+ALTER EVENT TRIGGER evt_new_name OWNER TO evt_second_owner;
+ALTER EVENT TRIGGER evt_new_name OWNER TO evt_first_owner;
+ERROR: permission denied to change owner of event trigger "evt_new_name"
+HINT: The owner of an event trigger must be a superuser.

Per the documentation, the five ALTER commands performed as evt_first_owner should have failed. They did not. At that time, evt_first_owner owned the event trigger despite not being a superuser.

The attempt later to assign ownership back to evt_first_owner fails claiming, "The owner of an event trigger must be a superuser", but that claim is not precisely true. At best, "The owner of an event trigger must be a superuser at the time ownership is transferred." There are similar oddities with some other object types which make a half-hearted attempt to require the owner to be a superuser, but I will start separate threads for those.

This behavior is weird enough that I don't know if it is the code or the documentation that is wrong. I'd like to post patches to clean this up, but need community feedback on whether it is the documentation or the behavior that needs adjusting.

Over in [1], I am trying to create new privileged roles and assign them some of the powers currently reserved to superuser. It is hard to make patches over there when the desired behavior of the system is not quite well defined.

[1] https://www.postgresql.org/message-id/214052.1627331086%40sss.pgh.pa.us

—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company