@@ -149,7 +149,7 @@ EXPLAIN SELECT * FROM pgbench_accounts WHERE filler LIKE '%x%';
149
149
which the system thinks that partial or incremental execution might
150
150
occur, no parallel plan is generated. For example, a cursor created
151
151
using <link linkend="sql-declare">DECLARE CURSOR</link> will never use
152
- a parallel plan. Similarly, a PL/pgsql loop of the form
152
+ a parallel plan. Similarly, a PL/pgSQL loop of the form
153
153
<literal>FOR x IN query LOOP .. END LOOP</literal> will never use a
154
154
parallel plan, because the parallel query system is unable to verify
155
155
that the code in the loop is safe to execute while parallel query is
@@ -478,7 +478,7 @@ EXPLAIN SELECT * FROM pgbench_accounts WHERE filler LIKE '%x%';
478
478
<para>
479
479
Functions and aggregates must be marked <literal>PARALLEL UNSAFE</> if
480
480
they write to the database, access sequences, change the transaction state
481
- even temporarily (e.g. a PL/pgsql function which establishes an
481
+ even temporarily (e.g. a PL/pgSQL function which establishes an
482
482
<literal>EXCEPTION</> block to catch errors), or make persistent changes to
483
483
settings. Similarly, functions must be marked <literal>PARALLEL
484
484
RESTRICTED</> if they access temporary tables, client connection state,