Migration vers 9.6 et supérieures

Fichier postgresql.conf

Le paramètre wal_level prend maintenant par défaut la valeur replica, équivalente à l’ancienne valeur hot_standby. Le niveau archive n’existe plus, car il y avait très peu de différences entre archive et hot_standby.

Les anciennes valeurs sont toujours acceptées, sachant que archive est assimilé au niveau replica, soit l’équivalent de hot_standby.

Vue pg_stat_activity

La colonne waiting de la vue pg_stat_activity n’existe plus, elle est remplacée par deux nouvelles colonnes :

• wait_event_type indiquant le type d’événement d’attente si le processus est en attente (et NULL sinon) ;
• wait_event indiquant le nom précis de l’événement d’attente si le processus est en attente (et NULL sinon).

Depuis la version 9.2, trouver les processus en attente se faisait de la façon suivante :

SELECT pid
FROM pg_stat_activity
WHERE waiting ;

À partir de la version 9.6, la requête suivante donne un résultat équivalent (un peu enrichi grâce à l’affichage des valeurs des nouvelles colonnes) :

SELECT pid, wait_event_type, wait_event
FROM pg_stat_activity
WHERE wait_event_type IS NOT NULL ;

Fonction to_char()

Lorsque la fonction to_char() est utilisée avec des données temporelles en entrée, elle ignore maintenant le symbole - lorsque c’est nécessaire. Par exemple, avec PostgreSQL 9.5 :

db95=# SELECT to_char('-4 years'::interval, 'YY') ;
 to_char 
---------
 -4
(1 ligne)

Avec PostgreSQL 9.6 :

db96=# SELECT to_char('-4 years'::interval, 'YY') ;
 to_char 
---------
 -04
(1 ligne)

Fonction extract()

Historiquement, la fonction extract() renvoyait systématiquement 0 lorsqu’elle était appelée avec un timestamp avec la valeur infinity, sans considérer le champ à extraire. Dorénavant, la fonction renvoie :

• infinity ou -infinity (respectivement au timestamp en entrée) lorsque le champ à extraire est à croissance monotone (year, epoch…) ;
• NULL lorsque ce n’est pas le cas (day, hour…) ;
• une erreur si le champ à extraire spécifié n’existe pas.

PL/pgSQL

Historiquement, la ligne CONTEXT normalement renvoyée dans les messages émis par la commande RAISE était supprimée de l’affichage. La rétrocompatibilité de ce comportement n’est désormais plus assurée, les messages émis par RAISE affichent donc une ligne CONTEXT comme les autres messages d’erreur.

Avec PostgreSQL 9.5 :

db95=# DO LANGUAGE plpgsql $$
db95$# BEGIN
db95$# RAISE 'test' ;
db95$# END;
db95$# $$
db95-# ;
ERROR:  test

Avec PostgreSQL 9.6 :

db95=# DO LANGUAGE plpgsql $$
db95$# BEGIN
db95$# RAISE 'test' ;
db95$# END;
db95$# $$
db95-# ;
ERROR:  test
CONTEXT:  PL/pgSQL function inline_code_block line 3 at RAISE

Full text search

Le parser plain text par défaut a été corrigé pour détecter les adresses e-mail et les noms d’hôte même si les premiers caractères sont numériques, ce qui n’était pas le cas précédemment. Dans la plupart des cas, ce changement va provoquer quelques variations mineures dans le parcours d’un texte. Néanmoins si ce type de chaîne apparaît fréquemment dans vos données, il peut être utile de reconstruire les colonnes tsvector et les index dépendants afin qu’elles soient identifiées correctement par les recherches plain text.

Avec PostgreSQL 9.5 :

db95=# select * from ts_debug('pg_catalog.english', '5432@example.com');
 alias |   description    |    token    | dictionaries | dictionary |    lexemes    
-------+------------------+-------------+--------------+------------+---------------
 uint  | Unsigned integer | 5432        | {simple}     | simple     | {5432}
 blank | Space symbols    | @           | {}           |            | 
 host  | Host             | example.com | {simple}     | simple     | {example.com}
(3 lignes)

Avec PostgreSQL 9.6 :

db96=# select * from ts_debug('pg_catalog.english', '5432@example.com');
 alias |  description  |      token       | dictionaries | dictionary |      lexemes       
-------+---------------+------------------+--------------+------------+--------------------
 email | Email address | 5432@example.com | {simple}     | simple     | {5432@example.com}
(1 row)

Contrib unaccent

Extension du fichier standard unaccent.rules pour prendre en compte tous les signes diacritiques prévus dans Unicode, et pour gérer les ligatures correctement. La version précédente négligeait de convertir certaines lettres avec signes diacritiques peu communes. Également, les ligatures sont désormais décomposées en lettres séparées. Les installations utilisant ce fichier de règles devraient reconstruire les colonnes tsvector et les index qui dépendent du résultat.

Avec PostgreSQL 9.5 :

db95=# SELECT ts_lexize('unaccent','Æ œ Ǎ ß ḭ ...') ;
     ts_lexize     
-------------------
 {"A e Ǎ S ḭ ..."}
(1 ligne)

Avec PostgreSQL 9.6 :

db96=# SELECT ts_lexize('unaccent','Æ œ Ǎ ß ḭ ...') ;
      ts_lexize       
----------------------
 {"AE oe A ss i ..."}
(1 ligne)

Commande CREATE ROLE

Les options dépréciées CREATEUSER/NOCREATEUSER de la commande CREATE ROLE et de commandes similaires sont désormais retirées. Cette option, qui correspond à SUPERUSER/NOSUPERUSER, est obsolète de longue date et avait été maintenue pour rétrocompatibilité. Elle est supprimée pour éviter des confusions avec CREATEROLE/NOCREATEROLE.

Restriction sur les noms de rôles

Les noms de rôle commençant par pg_ sont désormais traités comme des noms réservés. Il est donc désormais interdit de créer des rôles avec ce préfixe pour éviter les conflits avec les rôles internes créés par initdb.

Vue information_schema.routines

La colonne result_cast_character_set_name de la vue information_schema.routines est renommée en result_cast_char_set_name. Le standard SQL:2011 spécifie bien le nom result_cast_character_set_name, mais cela semble être une erreur du standard, car les autres colonnes de la vue et d’autres vues du schéma information_schema utilisent l’abréviation char.

psql

L’option -c (--command) de psql n’implique désormais plus automatiquement l’option -X (--no-psqlrc). Pour obtenir un comportement similaire à celui antérieur, il faut désormais spécifier explicitement --no-psqlrc.

pg_restore

L’option -t (--table) de pg_restore permet désormais de spécifier n’importe quel type de relation, pas seulement une table.

NextXID dans le pg_controldata

Modification du format d’affichage de l’information NextXID dans pg_controldata et plusieurs autres emplacements liés. L’information epoch-and-transaction-ID est désormais représentée sous la forme number:number. La représentation antérieure number/number était trop similaire avec le format utilisé pour la représentation des LSNs.

Extensions et parallélisme

De nombreuses extensions standard ont été mises à jour pour marquer leurs fonctions compatibles avec le parallélisme parallel-safe. Cela permet à des processus workers d’exécuter ces fonctions. Ces modifications ne seront pas appliquées automatiquement dans les bases de données migrées depuis les versions précédentes à l’aide de pg_upgrade, à moins d’appeler ALTER EXTENSION UPDATE pour chaque extension (dans chaque base de données de l’instance migrée).