docs(7.19): the RLS restriction on derived variables, and the startup Show log button #23
@@ -120,6 +120,7 @@ Derived columns themselves are an EDIT screen feature: the VIEW screen and the d
|
||||
- **Dependencies declared.** `VAR_DEPS` lists every input the expression uses - physical columns and derived variables alike. Statements are generated in dependency order, so no sequence number is maintained, and the declaration is checked in both directions: every reference must be declared, and every declared name must be referenced and must exist. Circular references are rejected.
|
||||
- **No collisions.** `VAR_NM` must not match an existing column of the target table, or `_____DELETE__THIS__RECORD_____`.
|
||||
- **Read-only.** Derived columns cannot be edited in the grid, and any value submitted for them is discarded before the approval package is created.
|
||||
- **Label is free text.** `VAR_LABEL` takes any characters, in any script - quotes are escaped when the statement is generated - but it is a column label, so it is one line: control characters and line breaks are refused, and so is a value over 256 characters, which the engine would otherwise cut down silently.
|
||||
- **Not for row level security.** A derived variable cannot be named by an active [row level security](/row-level-security/) rule, of any scope. RLS rules are validated against the physical table, where a derived column does not exist, so a rule naming one is rejected when it is submitted.
|
||||
- **Recomputed on every read.** The value always reflects the current data and the current definition, and there is no history of previous derived values.
|
||||
|
||||
|
||||
Reference in new issue
Block a user