@@ -149,7 +149,7 @@ EXPLAIN SELECT * FROM pgbench_accounts WHERE filler LIKE '%x%';
149149 which the system thinks that partial or incremental execution might
150150 occur, no parallel plan is generated. For example, a cursor created
151151 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
153153 <literal>FOR x IN query LOOP .. END LOOP</literal> will never use a
154154 parallel plan, because the parallel query system is unable to verify
155155 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%';
478478 <para>
479479 Functions and aggregates must be marked <literal>PARALLEL UNSAFE</> if
480480 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
482482 <literal>EXCEPTION</> block to catch errors), or make persistent changes to
483483 settings. Similarly, functions must be marked <literal>PARALLEL
484484 RESTRICTED</> if they access temporary tables, client connection state,