Le E devant une chaîne de caractères indique que l'antislash dans cette chaîne est un caractère d'échappement, sinon c'est un caractère normal (enfin sauf si standard_conforming_strings est à OFF mais en postgres moderne, il devrait être à ON).

Dans la doc c'est décrit ici: https://docs.postgresql.fr/10/sql-synta … ngs-escape

Vous pouvez utiliser LEAD avec un fenêtrage, qui donne la valeur d'une colonne sur les lignes suivantes par rapport à un ordre spécifié explicitement.

Par exemple:

SELECT autres colonnes,
  lead(count_row,1) over(w) as suivant1,
  lead(count_row,2) over(w) as suivant2,
  lead(count_row,3) over(w) as suivant3
FROM table
WINDOW w AS (ORDER BY date)

La condition que vous voulez est satisfaite quand suivant1 et suivant2 et suivant3 sont tous à zéro.

Attention au fait que LEAD(colonne, N) renvoie NULL quand le décalage N sort des limites du jeu de données.

Que les temps d'exécution soient très variables peut aussi venir du fait que le sous-système disque serait virtualisé.

C'est facile à gérer pour les admins (peut-être que le doublage de taille de la partition a juste consisté à bouger une réglette dans une interface?) mais les performances sont imprévisibles puisque les disques physiques sont partagés par plusieurs machines virtuelles.

Même sur un système disque dédié, les temps sont variables, pour bien faire il faut enchaîner entre 5 et 10 exécutions du test et considérer le temps médian comme résultat.

Si la colonne est de type timestamptz ou timestamp.

Méthode qui tire partie de l'index s'il y en a un sur cette colonne:

SELECT * FROM table
 WHERE colonne_date >= '2017-01-01'::date
   AND colonne_date < '2018-01-01'::date;

Méthode peut-être plus intuitive mais  généralement moins efficace par rapport à un index:

SELECT * FROM table
 WHERE date_part('year', colonne_date) = 2017

Oui ça a l'air normal si les connexions viennent de 192.168.103.191 , et au passage le pg_hba.conf est illogique:

host    all             all             192.168.103.191/32      trust
host    all             postgres        192.168.103.191/32      trust
host    all             barman          192.168.103.191/32      md5

En 1ere ligne, ça dit "toute connexion venant de 192.168.103.191 est autorisée sans mot de passe, pour toute base (all) et pour tout utilisateur (all).

La 2eme ligne dit la même chose mais uniquement pour l'utilisateur postgres, sauf que le pg_hba.conf applique les règles dans l'ordre et donc la 1ere ligne gagnera toujours.

La 3eme dit que l'utilisateur barman doit envoyer son mot de passe (md5) sauf que pour les mêmes raisons cette ligne n'aura jamais aucun effet,  la ligne 1 étant prioritaire.

il faudrait exporter et importer séparément la structure et les données, pour éviter de passer la recherche/remplacement sur les données, qui est coûteuse mais aussi dangereuse (si le contenu recherché s'avère être présent dans les données par coïncidence).

Voir les options de pg_dump --schema-only et --data-only

l'OID est un nombre de 4 octets, utilisé en entier non signé et dont les valeurs vont de 0 à (2 puissance 32)-1 (=4294967295)

L'UUID n'est pas un concept propre à postgres, il correspond à une norme décrite par exemple ici:
https://fr.wikipedia.org/wiki/Universal … Identifier

La différence la plus évidente est qu'il comporte 16 octets, donc il prend 4 fois plus de place mais peut représenter 2 puissance 128 valeurs.

La table matrice_total_test est dépivotée ce qui va dans le bon sens, mais la forme de ces données (enfin à supposer que  je comprends ce qu'elles représentent) est telle qu'il y aurait 2 dépendances:

id de polygone=> geom
(id de polygone, année) => valeur

D'un pt de vue un peu théorique, le fait d'avoir ces données dans la même table  matrice_total_test est une violation de la 2eme forme normale.
Les formes normales sont décrites par exemple ici:
https://fr.wikipedia.org/wiki/Forme_nor … ionnelles)

Le problème que geom ne dépend en rien de l'année est similaire structurellement à l'exemple wikipedia avec (Produit, fournisseur, Adresse fournisseur).

Je pense que pour avoir cette erreur il faut un mélange de sources compilées avec openssl et sans openssl.

Pour corriger, il faudrait nettoyer le répertoire de compil avec un "make distclean" à la racine des source
et ensuite lancer à nouveau le configure et le make.

Le souci avec les années en colonnes, c'est que ça ne respecte pas le modèle relationnel. Dans ce modèle on a des relations (=tables), des attributs (=colonnes) et des valeurs (=contenu des colonnes)

Or "typeannée2016" n'est pas un attribut. Par contre "année" est un attribut, et 2016 est une valeur possible de cet attribut. Et sans trop savoir ce que désigne "type" , ça  a l'air d'être un attribut, et "type_1" est une valeur possible de cet attribut

Concrètement dans le modèle relationnel ces données pourraient être avoir cette forme:

TABLE polygone(
 id int PRIMARY KEY,
 geom geometry
)

TABLE mesure(
  id int REFERENCES polygone(id),
  annee int,
  valeur varchar 
);

avec éventuellement un index unique sur le couple (id,annee) parce que la valeur est fonction de (id,annee).
Cette structure permet d'accueillir de nouvelles années sans changer les colonnes, mais surtout d'être requêtée en SQL parce qu'elle est alignée avec la logique relationnelle.

Ce qui ne veut pas dire que les requêtes vont être forcément simples à élaborer, tout dépend des questions auxquelles elles doivent répondre, mais qu'au moins toutes les fonctionnalités du SQL seront utilisables directement.

Une approche plus orthodoxe serait de faire un dictionnaire personnalisé qui éliminerait les léxèmes dépassant la longueur en question, qui peut d'ailleurs être un paramètre du dictionnaire.

L'inconvénient c'est qu'il faut le faire en C. Mais si vous en êtes à recompiler postgres, ce n'est pas forcément un problème.

Le code à produire est très simple en s'inspirant de  src/backend/tsearch/dict_simple.c.

Les exemples dans contrib dict_int, dict_xsyn permettent aussi de voir comment packager ça dans une extension avec les déclarations de dictionnaire qui vont bien.

Merci pour le retour positif sur les pivots dynamiques!

Sur ce problème

typiquement il faut imbriquer les calculs en sous-requête, du style:

 SELECT avg(s.v) FROM (select sum(valeur) AS v FROM table GROUP BY qqch) AS s;

Les requêtes les plus complexes peuvent avoir beaucoup de niveaux d'imbrication, et mentalement on conçoit ces niveaux d'imbrication séparément pour arriver à comprendre ou produire ces requêtes.

Pour la question sur choisir Rstat ou des solutions équivalentes ou SQL, personnellement n'y connaissant rien en statistiques, je ne me rends pas vraiment compte de ce qu'on fait avec et si c'est mieux ou non.

En regardant la procédure de Sotos sur  https://forums.postgresql.fr/viewtopic.php?id=4478 ce qui me paraît notable c'est que pour son traitement toutes les colonnes numériques d'une table se valent. C'est-à-dire que sa procédure va calculer un paquet de statistiques sur les colonnes sans s'occuper de savoir si c'est un nombre de personnes, une durée en secondes, une taille, une surface... Cette manière d'aborder les données est plutôt étrange du point de vue du mode de pensée relationnel, dans lequel chaque colonne a un sens individuellement, et donc l'idée de considérer les colonnes de manière générique sort du cadre naturel.