PostgreSQL 17 Beta was released on May 23, 2024, introducing a host of exciting new features anticipated to be part of the official PostgreSQL 17 release. In this blog series, we’ll delve into these features and explore how they can benefit database developers and migration engineers transitioning to the latest PostgreSQL version.
First part of the blog is on newer features with PL\pgSQL – Procedural language in PostgreSQL 17.
PL/pgSQL is the default procedural language preinstalled on PostgreSQL whenever a new database is created. It is a loadable procedural language that follows a block-based structure, making it easier to wrap functional logic in stored code as functions or procedures.
As part of the PostgreSQL 17 Beta release, the following additions have been made to PL/pgSQL:
- Allow plpgsql %TYPE and %ROWTYPE specifications to represent arrays of non-array types (Quan Zongliang, Pavel Stehule)
- Allow plpgsql %TYPE specification to reference composite column (Tom Lane)
New Array Type Declarations in PL/pgSQL with PostgreSQL 17
With PostgreSQL 17, we can now directly declare array types based on the primitive type of columns, or using row types from tables or user-defined types with %TYPE or %ROWTYPE.
Prior to PostgreSQL 17, if we needed to declare an array variable, we couldn’t use %TYPE or %ROWTYPE to refer to the underlying database type. Instead, we had to manually note the underlying data type and use it explicitly in the array declaration.
PostgreSQL 17 simplifies this process. Now, using %TYPE and %ROWTYPE, we can define array variables based on the types of underlying database objects like columns, tables, or user-defined types. Moreover, we can similarly declare additional array variables using underlying variables types.
Lets create a sample table and type to understand with an sql snippet.
--PostgreSQL 17 Beta
create table testplpgsql17
as
select col1, col1::text as col2, col1*9.9 as col3
from generate_series(1,10) as col1;
create type typesample as (col1 integer);
We will use the latest feature to declare array types based on the underlying table and its columns’ data types.
--PostgreSQL 17 Beta Simplified Example
do language plpgsql
$$
<<block1>>
declare
var1 testplpgsql17.col1%type[];
var2 testplpgsql17%rowtype[];
begin
SELECT array_agg(col1),array_agg(tbl.*)
into var1, var2
FROM (select * from testplpgsql17 limit 2) as tbl ;
raise notice 'PL\pgSQL PG 17 - type[] - %',var1;
raise notice 'PL\pgSQL PG 17 - rowtype[] - %',var2;
end block1;
$$;
Additional examples to show multiple variants of using array declarations for %TYPE and %ROWTYPE.
--Do Block
do language plpgsql
$$
<<block1>>
declare
var1 testplpgsql17.col1%type[];
var2 testplpgsql17%rowtype[];
var3 var1%type[]; -- array of variable type
var4 var2%type[]; -- array of variable rowtype
var5 typesample.col1%type[]; --array of attribute type within Type
var6 typesample%rowtype[];--array of type within type
var7 block1.var1%type[];
begin
SELECT array_agg(col1),array_agg(tbl.*)
into var1, var2
FROM (select * from testplpgsql17 limit 2) as tbl ;
var3 := ARRAY[var1];
var4 := ARRAY[var2];
raise notice 'PL\pgSQL PG 17 - type[][] - %',var3;
raise notice 'PL\pgSQL PG 17 - rowtype[][] - %',var4;
SELECT array_agg(col1),array_agg(row(col1))
into var5, var6
FROM (select * from testplpgsql17 limit 2) as tbl;
raise notice
'PL\pgSQL PG 17 - user defined type[] [] - %',var5;
raise notice
'PL\pgSQL PG 17 - user defined rowtype[][] - %',var6;
end block1;
$$;
In the sample shared, we have tested different variants that use the newer syntax to declare arrays of %TYPE or %ROWTYPE. We can also use this syntax to declare arrays based on existing variables, as shown with the var3 and var4 examples.
In conclusion, the new array type declarations introduced in PL/pgSQL with PostgreSQL 17 significantly ease and simplify the process of declaring array variables. With direct reference to underlying %TYPE or %ROWTYPE, developers can now declare arrays more efficiently, enhancing the readability and maintainability of their code. These enhancements not only streamline development but also empower developers to harness the full potential of PostgreSQL 17 in their projects.