languages with the base distribution:
- linkend="plpgsql">PL/PgSQL, PL/Tcl,
+ linkend="plpgsql">PL/pgSQL, PL/Tcl,
PL/Perl, and
linkend="plpython">PL/Python.
- use in PL/PgSQL
+ use in PL/pgSQL
- use in PL/PgSQL
+ use in PL/pgSQL
- use in PL/PgSQL
+ use in PL/pgSQL
RETURN NEXT> and RETURN QUERY
- in PL/PgSQL
+ in PL/pgSQL
- in PL/PgSQL
+ in PL/pgSQL
- in PL/PgSQL
+ in PL/pgSQL
- in PL/PgSQL
+ in PL/pgSQL
files during postmaster startup
Various memory leakage fixes
Various portability improvements
-
Fix PL/PgSQL to handle var := var> correctly when
+
Fix PL/pgSQL to handle var := var> correctly when
the variable is of pass-by-reference type
Update contrib/tsearch2> to use current Snowball
code
constraints more reliably
Fix password prompting in pg_restore> on
Windows
-
Fix PL/PgSQL to handle var := var> correctly when
+
Fix PL/pgSQL to handle var := var> correctly when
the variable is of pass-by-reference type
Fix PL/Perl %_SHARED> so it's actually
shared
- Fix PL/PgSQL to not fail when a FOR> loop's target variable
+ Fix PL/pgSQL to not fail when a FOR> loop's target variable
is a record containing composite-type fields (Tom)
- Allow SQL and PL/PgSQL functions to use OUT> and
+ Allow SQL and PL/pgSQL functions to use OUT> and
INOUT> parameters (Tom)
-
PL/PgSQL Server-Side Language Changes
+
PL/pgSQL Server-Side Language Changes
- Overhaul the memory management of PL/PgSQL functions (Neil)
+ Overhaul the memory management of PL/pgSQL functions (Neil)
The parsetree of each function is now stored in a separate
Add support for an optional INTO> clause to
- PL/PgSQL's EXECUTE> statement (Pavel Stehule, Neil)
+ PL/pgSQL's EXECUTE> statement (Pavel Stehule, Neil)
- Fix PL/PgSQL to not fail when a FOR> loop's target variable
+ Fix PL/pgSQL to not fail when a FOR> loop's target variable
is a record containing composite-type fields (Tom)
-
PL/PgSQL Server-Side Language Changes
+
PL/pgSQL Server-Side Language Changes
linkend="guc-local-preload-libraries">local_preload_libraries>
that allows libraries to be loaded into specific sessions without
explicit cooperation from the client application. This allows
- external add-ons to implement features such as a PL/PgSQL debugger.
+ external add-ons to implement features such as a PL/pgSQL debugger.
- Fix PL/PgSQL to not fail when a FOR> loop's target variable
+ Fix PL/pgSQL to not fail when a FOR> loop's target variable
is a record containing composite-type fields (Tom)
- Previously PL/PgSQL functions that referenced temporary tables
+ Previously PL/pgSQL functions that referenced temporary tables
would fail if the temporary table was dropped and recreated
between function invocations, unless EXECUTE> was
used. This improvement fixes that problem and many related issues.
The first request for statistics in a transaction takes a statistics
snapshot that does not change during the transaction. This function
allows the snapshot to be discarded and a new snapshot loaded during
- the next statistics query. This is particularly useful for PL/PgSQL
+ the next statistics query. This is particularly useful for PL/pgSQL
functions, which are confined to a single transaction.
-
PL/PgSQL Server-Side Language
+
PL/pgSQL Server-Side Language
Allow IN as an alternative to
- FROM in PL/PgSQL's FETCH
+ FROM in PL/pgSQL's FETCH
statement, for consistency with the backend's
FETCH command (Pavel Stehule)
- Add MOVE to PL/PgSQL (Magnus, Pavel Stehule,
+ Add MOVE to PL/pgSQL (Magnus, Pavel Stehule,
Neil)
- This adds convenient syntax for PL/PgSQL set-returning functions
+ This adds convenient syntax for PL/pgSQL set-returning functions
that want to return the result of a query. RETURN QUERY>
is easier and more efficient than a loop
around RETURN NEXT.
- In particular, this means that functions written in PL/PgSQL
+ In particular, this means that functions written in PL/pgSQL
and other PL languages can now be called this way.
-
PL/PgSQL Server-Side Language
+
PL/pgSQL Server-Side Language
-
PL/PgSQL Server-Side
+
PL/pgSQL Server-Side
Language
enabled
Various memory leakage fixes
Various portability improvements
-
Fix PL/PgSQL to handle var := var> correctly when
+
Fix PL/pgSQL to handle var := var> correctly when
the variable is of pass-by-reference type
}
/*
- * When the PL/PgSQL parser expects to see a SQL statement, it is very
+ * When the PL/pgSQL parser expects to see a SQL statement, it is very
* liberal in what it accepts; for example, we often assume an
* unrecognized keyword is the beginning of a SQL statement. This
* avoids the need to duplicate parts of the SQL grammar in the
- * PL/PgSQL grammar, but it means we can accept wildly malformed
+ * PL/pgSQL grammar, but it means we can accept wildly malformed
* input. To try and catch some of the more obviously invalid input,
* we run the strings we expect to be SQL statements through the main
* SQL parser.
* any database access and does not check any semantic rules, it just
* checks for basic syntactic correctness. We do this here, rather
* than after parsing has finished, because a malformed SQL statement
- * may cause the PL/PgSQL parser to become confused about statement
+ * may cause the PL/pgSQL parser to become confused about statement
* borders. So it is best to bail out as early as we can.
*
* It is assumed that "stmt" represents a copy of the function source text
* per-function memory context, so it can be reclaimed easily.
*/
func_cxt = AllocSetContextCreate(TopMemoryContext,
- "PL/PgSQL function context",
+ "PL/pgSQL function context",
ALLOCSET_DEFAULT_MINSIZE,
ALLOCSET_DEFAULT_INITSIZE,
ALLOCSET_DEFAULT_MAXSIZE);
* its own memory context, so it can be reclaimed easily.
*/
func_cxt = AllocSetContextCreate(CurrentMemoryContext,
- "PL/PgSQL function context",
+ "PL/pgSQL function context",
ALLOCSET_DEFAULT_MINSIZE,
ALLOCSET_DEFAULT_INITSIZE,
ALLOCSET_DEFAULT_MAXSIZE);
exec_stmt_return(PLpgSQL_execstate *estate, PLpgSQL_stmt_return *stmt)
{
/*
- * If processing a set-returning PL/PgSQL function, the final RETURN
+ * If processing a set-returning PL/pgSQL function, the final RETURN
* indicates that the function is finished producing tuples. The rest of
* the work will be done at the top level.
*/
ERROR: IFace slotname "IF.orion.ethernet_interface_name_too_long" too long (20 char max)
--
-- The following tests are unrelated to the scenario outlined above;
--- they merely exercise specific parts of PL/PgSQL
+-- they merely exercise specific parts of PL/pgSQL
--
--
-- Test recursion, per bug report 7-Sep-01
--
-- The following tests are unrelated to the scenario outlined above;
--- they merely exercise specific parts of PL/PgSQL
+-- they merely exercise specific parts of PL/pgSQL
--
--