Add OWNER TO clause to alter-trigger.md and update documentation for

task and trigger execution identity

Author: joocer

docs-site/reference/sql/statements/alter-trigger.md

@@ -5,7 +5,8 @@ description: SQL ALTER TRIGGER statement syntax and examples for suspending and
 
 # ALTER TRIGGER
 
-The `ALTER TRIGGER` statement suspends or resumes one trigger.
+The `ALTER TRIGGER` statement suspends or resumes one trigger, or transfers the identity
+its unattended runs execute as.
 
 A suspended trigger still exists and is still reached when its table commits; it simply
 enqueues nothing and records that it was suppressed. Prefer this to
@@ -19,6 +20,10 @@ deliberately, when, and by whom.
 ALTER TRIGGER <trigger_name>
     ON <table_name>
     { SUSPEND | RESUME };
+
+ALTER TRIGGER <trigger_name>
+    ON <table_name>
+    OWNER TO { <principal> | CURRENT_USER };
 ~~~
 
 ## Parameters
@@ -29,6 +34,9 @@ ALTER TRIGGER <trigger_name>
   `<workspace>.<collection>.<table_name>`.
 - `SUSPEND` — stop the trigger firing, keeping it in place.
 - `RESUME` — let it fire again.
+- `OWNER TO` — transfer the identity the trigger's runs execute as. The incoming owner
+  must be a user or a service account — platform identities are refused, because they
+  carry no billing account and the trigger's runs are billed to its owner.
 
 ## Examples
 
@@ -42,6 +50,11 @@ ALTER TRIGGER ingest_on_events ON my_workspace.raw.events SUSPEND;
 ALTER TRIGGER ingest_on_events ON my_workspace.raw.events RESUME;
 ~~~
 
+### Transfer Its Owner
+~~~sql
+ALTER TRIGGER ingest_on_events ON my_workspace.raw.events OWNER TO svc_ingest;
+~~~
+
 ## Notes
 
 - Requires the `writer` role on the table the trigger is attached to, the same as creating

docs-site/reference/sql/statements/create-task.md

@@ -13,9 +13,10 @@ re-runs one `SELECT` into its own backing table, a task runs any statement the e
 plan — typically an `INSERT` that appends only what changed, which is what makes it
 suitable for tables too large to rebuild.
 
-A task runs as its owner, so creating one is not merely registering some SQL: it creates
-something that executes with an identity. What you may define is therefore bounded by what
-you could already run yourself — see [Notes](#notes).
+A task carries no identity of its own. Running one with [EXECUTE](execute) runs it as
+**you**, gated by your own permissions at that moment; an unattended run carries the
+identity of the [trigger](create-trigger) that fired it. Creating a task therefore
+confers no authority — see [Notes](#notes).
 
 ## Syntax
 
@@ -37,7 +38,8 @@ CREATE [ OR REPLACE ] TASK <task_name>
 - **`<statement>`** — the SQL the task runs. It may contain `:name` placeholders, which are
   supplied when the task is executed rather than now.
 - `OR REPLACE` — redefine an existing task instead of refusing. The previous statement is
-  kept as an earlier version, and the task's owner is **not** changed.
+  kept as an earlier version, and triggers pointing at the task are untouched — including
+  whose identity they run it as.
 
 ## Examples
 
@@ -78,16 +80,14 @@ CREATE OR REPLACE TASK my_workspace.ops.ingest_events AS
 
 ## Notes
 
-- **You may only create a task you could run yourself.** Creating one requires `reader` on
-  everything the statement reads and `writer` where it writes, checked against you at the
-  time you create it and again every time you redefine it. Without that, a task would let
-  anyone define work over data they cannot see and have a privileged identity run it.
-- **The task runs as you.** There is no syntax for naming another principal — an argument
-  that could is the escalation above, written out. Ownership survives `OR REPLACE`, so
-  editing a task never quietly transfers whose authority it runs with.
-- **Platform identities cannot own tasks.** They can read a great deal but have no billing
-  account, so a task pinned to one would run on a schedule forever and land on nobody's
-  bill. Own a task as a user or a service account.
+- **Creating a task checks nothing but the name.** A task is stored SQL: its statement is
+  gated when it *runs*, against whoever the run actually is — you, for `EXECUTE`; the
+  trigger's owner, for a fired run. A creation-time copy of those checks would be checked
+  against the wrong principal the moment anyone else ran it.
+- **`ON <table>` is the exception**, because it creates a trigger — and a trigger's
+  unattended runs execute as its owner, pinned to you. So the `ON` form additionally
+  requires `writer` on that table and that you are an identity that can be billed, the
+  same gates [CREATE TRIGGER](create-trigger) applies.
 - The statement is parsed when the task is created, so SQL that could never run is refused
   now rather than discovered when it fires. It is not fully planned — a task's placeholders
   have no values yet, and planning would demand them.

docs-site/reference/sql/statements/create-trigger.md

@@ -63,9 +63,15 @@ CREATE OR REPLACE TRIGGER ingest_on_events
 ## Notes
 
 - Requires the `writer` role on the **table** the trigger is attached to — landing a
-  trigger is an update to that table. It does not require any permission on the task: a
-  trigger confers no authority of its own, and what the task may do was settled against its
-  author when the task was created.
+  trigger is an update to that table.
+- **The trigger's runs execute as its owner, which is pinned to you.** The trigger is what
+  makes a run unattended, so the trigger is what names whose authority the run carries.
+  The task's statement is gated against that owner every time it fires — nothing is
+  settled once at creation and left to go stale. Move the owner with
+  [ALTER TRIGGER ... OWNER TO](alter-trigger).
+- **Platform identities cannot own triggers.** They can read a great deal but have no
+  billing account, so work pinned to one would run on a schedule forever and land on
+  nobody's bill. Own a trigger as a user or a service account.
 - A fired task is passed the committing snapshot and its parent, as `:current_version` and
   `:parent_version`. The window is fixed when the trigger fires, so a run means the same
   thing however long afterwards it is picked up.

docs-site/reference/sql/statements/execute.md

@@ -53,6 +53,9 @@ EXECUTE my_workspace.ops.ingest_new
 
 ## Notes
 
+- **The task runs as you.** `EXECUTE` is an attended run: the statement is gated against
+  your own permissions, exactly as if you had typed it. Only an unattended run — a
+  [trigger](create-trigger) firing — carries a pinned identity, the trigger's owner.
 - Arguments must be **constants**. A column reference is refused: a task's arguments are
   bound when it runs, not evaluated against a relation.
 - Values are substituted into the task's statement only after that statement has been