diff options
| author | Tom Lane <tgl@sss.pgh.pa.us> | 2019-01-09 11:35:14 -0500 |
|---|---|---|
| committer | Tom Lane <tgl@sss.pgh.pa.us> | 2019-01-09 11:35:14 -0500 |
| commit | 59029b6fb71e187c150d12f4c37bb2bf982d3125 (patch) | |
| tree | 5ef9f96b6ac3219e28e889f30a0171a111a9e078 /doc/src | |
| parent | a2b22d8e804511ca7f0f712e8365a6a013b0254e (diff) | |
| download | postgresql-59029b6fb71e187c150d12f4c37bb2bf982d3125.tar.gz postgresql-59029b6fb71e187c150d12f4c37bb2bf982d3125.zip | |
Update docs & tests to reflect that unassigned OLD/NEW are now NULL.
For a long time, plpgsql has allowed trigger functions to parse
references to OLD and NEW even if the current trigger event type didn't
assign a value to one or the other variable; but actually executing such
a reference would fail. The v11 changes to use "expanded records" for
DTYPE_REC variables changed the behavior so that the unassigned variable
now reads as a null composite value. While this behavioral change was
more or less unintentional, it seems that leaving it like this is better
than adding code and complexity to be bug-compatible with the old way.
The change doesn't break any code that worked before, and it eliminates
a gotcha that often required extra code to work around.
Hence, update the docs to say that these variables are "null" not
"unassigned" when not relevant to the event type. And add a regression
test covering the behavior, so that we'll notice if we ever break it
again.
Per report from Kristjan Tammekivi.
Discussion: https://postgr.es/m/CAABK7uL-uC9ZxKBXzo_68pKt7cECfNRv+c35CXZpjq6jCAzYYA@mail.gmail.com
Diffstat (limited to 'doc/src')
| -rw-r--r-- | doc/src/sgml/plpgsql.sgml | 4 | ||||
| -rw-r--r-- | doc/src/sgml/release-11.sgml | 18 |
2 files changed, 19 insertions, 3 deletions
diff --git a/doc/src/sgml/plpgsql.sgml b/doc/src/sgml/plpgsql.sgml index 1f2abbb5d17..f8c6435c50e 100644 --- a/doc/src/sgml/plpgsql.sgml +++ b/doc/src/sgml/plpgsql.sgml @@ -3849,7 +3849,7 @@ ASSERT <replaceable class="parameter">condition</replaceable> <optional> , <repl <para> Data type <type>RECORD</type>; variable holding the new database row for <command>INSERT</command>/<command>UPDATE</command> operations in row-level - triggers. This variable is unassigned in statement-level triggers + triggers. This variable is null in statement-level triggers and for <command>DELETE</command> operations. </para> </listitem> @@ -3861,7 +3861,7 @@ ASSERT <replaceable class="parameter">condition</replaceable> <optional> , <repl <para> Data type <type>RECORD</type>; variable holding the old database row for <command>UPDATE</command>/<command>DELETE</command> operations in row-level - triggers. This variable is unassigned in statement-level triggers + triggers. This variable is null in statement-level triggers and for <command>INSERT</command> operations. </para> </listitem> diff --git a/doc/src/sgml/release-11.sgml b/doc/src/sgml/release-11.sgml index f35b0d8cc93..b129d32264c 100644 --- a/doc/src/sgml/release-11.sgml +++ b/doc/src/sgml/release-11.sgml @@ -1033,6 +1033,23 @@ Branch: REL9_3_STABLE [84261eb10] 2018-10-19 17:02:26 -0400 </para> </listitem> + <listitem> +<!-- +2018-02-13 [4b93f5799] Make plpgsql use its DTYPE_REC code paths for composite- +--> + + <para> + In PL/pgSQL trigger functions, the <varname>OLD</varname> + and <varname>NEW</varname> variables now read as NULL when not + assigned (Tom Lane) + </para> + + <para> + Previously, references to these variables could be parsed but not + executed. + </para> + </listitem> + </itemizedlist> </sect2> @@ -2574,7 +2591,6 @@ same commits as above <listitem> <!-- 2018-02-13 [4b93f5799] Make plpgsql use its DTYPE_REC code paths for composite- - --> <para> |