Forums PostgreSQL.fr

Oui c'est bon si sur le secondaire-devenu-primaire, les index concernés sont recréés avant d'être utilisés dans des requêtes.
En pratique c'est souvent suffisant. En théorie ça ne gère pas tous les cas. Il peut y avoir des dépendances plus subtiles sur les collations, par exemple une contrainte CHECK column BETWEEN 'valeur1' AND 'valeur2', ou encore du PARTITION BY RANGE avec des valeurs texte, ou une contrainte CHECK avec une expression régulière dont le résultat dépend de la version d'Unicode.. Idéalement il faut vérifier les schémas des bases pour identifier ce genre de problème.

Le passage à glibc-2.28 a occasionné des différences de comparaison sur des chaînes de caractères tout à fait basiques.
Cf https://blog-postgresql.verite.pro/2018 … grade.html

Dans l'exemple ci-dessus le curseur retourné par la fonction s'appelle "<unnamed portal 3>" et il faudrait faire le FETCH avec cette syntaxe:

 FETCH ALL FROM "<unnamed portal 3>" ;

Par opposition, l'autre syntaxe FETCH ALL FROM :"curseur";  est faite pour le client psql et ne peut pas fonctionner avec DBeaver parce que curseur est une variable psql dans ce contexte.

Il est aussi possible à l'appelant d'imposer son nom de curseur à la fonction pour simplifier ça, dans ce cas utiliser la variante ici:

https://github.com/dverite/postgresql-f … cursor.sql

la fonction dynamic_pivot() prend un 3eme argument qui est le nom de curseur. Avec cette version, la séquence ci-dessous devrait fonctionner quel que soit le client SQL:

BEGIN;

select dynamic_pivot(
	'select id_echantillon, 
		 	id_type_analyse , 
		 	max(a.valeur) valeur 
		 	from t_analyse a where a.created >''2024-02-01''
		 	and  a.valeur IS NOT null and a."etat" = ''valide''
		 	group by id_echantillon, id_type_analyse',
	'select id_type_analyse from t_type_analyse',
   'moncurseur');

FETCH ALL FROM "moncurseur";

COMMIT;

\b dans la regex correspond dans Postgres au caractère de code 8 (backspace), qui n'a pas de raison d'être dans une URL (qui est probablement illégal dans une URL d'ailleurs vu que c'est un caractère de contrôle).
cf la doc: https://www.postgresql.org/docs/current … ching.html

En revanche dans Perl \b correspond à une limite (boundary), cf https://perldoc.perl.org/perlrebackslas … 7D%2C-%5CB

Moralité vous essayez une expression régulière qui marcherait sûrement avec Perl mais non compatible avec Postgres.

La doc de Perl ci-dessus dit que \b est équivalent à

(?:(?<=\w)(?!\w)|(?<!\w)(?=\w))

donc vous pouvez essayer de remplacer par cette séquence.

Il serait intéressant de voir ce que sortent ces commandes:

dpkg --get-selections 'postgres*'
systemctl list-units 'postgres*'

Vous pouvez provisoirement zapper les couches systemd et pg_ctlcluster en lançant à la main avec cette commande en qu'utilisateur postgres:

/usr/lib/postgresql/15/bin/pg_ctl \
  -D /var/lib/postgresql/15/main \
  -o "-c config_file=/etc/postgresql/15/main/postgresql.conf" \
 start

Le but n'étant pas tant de démarrer que d'avoir des erreurs à l'affichage, si ni /var/log/postgresql/postgresql-15-main.log ni  journalctl -u postgresql@15-main.service ne donnent pas d'indication.

Le contenu de la colonne JSON de grande taille est déjà compressé. La taille décompressée s'obtiendrait avec cette requête:

SELECT octet_length(nom_colonne::text)  FROM table WHERE ...

Vous pouvez exporter juste cette ligne/colonne dans un fichier texte pour la regarder en détail dans un éditeur, via ce genre de commande, sous psql:

\pset format unaligned
\pset tuples_only on
select nomdelacolonne FROM nomdelatable WHERE ... \g fichier-de-sortie.json

(ne pas terminer la requête par un point-virgule, c'est le \g qui termine la requête)

En supposant que vous ayez installé PostgreSQL sous Windows en  téléchargeant d'ici: https://www.enterprisedb.com/downloads/ … -downloads

Pendant l'installation il demande de choisir un mot de passe pour le compte postgres superutilisateur.

C'est ce mot de passe qu'il faut utiliser dans pgAdmin dans la boite de dialogue "Nouveau serveur", onglet Connexion, avec le nom d'utilisateur "postgres".

pgAdmin ne créé pas de serveur postgresql à proprement parler, il créé un objet à lui qu'il appelle serveur et qui contient toutes les données permettant de se connecter à une instance postgresql qu'on appelle aussi serveur.

En fait il y a beaucoup plus de différences.
Quelques exemples ici: https://blog-postgresql.verite.pro/2018 … grade.html

Seule la collation "C" ou "POSIX" offre une garantie absolue de permanence des tris lors des montées de version des OS, et de tri identique entre OS différents.

Les paquets Ubuntu/Debian configurent une rotation de log via lograte avec cette configuration:

$ cat /etc/logrotate.d/postgresql-common

/var/log/postgresql/*.log {
       weekly
       rotate 10
       copytruncate
       delaycompress
       compress
       notifempty
       missingok
       su root root
}

Remplacer weekly par daily dans ce fichier est le plus simple pour avoir un fichier par jour, sauf que le changement de fichier ne se fait pas exactement à 0h.

Si on veut exactement un fichier par jour 0h->minuit, il faut changer la configuration dans postgresql.conf avec logging_collector à on, un log_filename et un log_rotation_age personnalisés.

Dans le 1er message il est question de faire DELETE, pas DROP ni TRUNCATE qui effectivement ne sont pas possibles en présence des contraintes d'intégrité référentielles.

La collation influe sur le résultat de la comparaison des chaînes de caractères.

Ici la contrainte d'unicité sur (code_cad, code_ds, no_lot) implique qu'à l'insertion ou MAJ d'une ligne, le moteur vérifie qu'il n'y a pas déjà une valeur pour laquelle il y aurait code_cad=nouveau code_cad ET code_ds=nouveau code ds ET no_lot=nouveau no_lot.

Comme il y a une collation personnalisée affectée à la colonne no_lot, la comparaison no_lot=nouveau no_lot se fait avec cette collation. Sans savoir comment est définie cette collation (ça peut se voir avec select * from pg_collation WHERE collname='numeric') et quelle est la valeur de no_lot qu'il ne reconnait pas comme un doublon alors que c'en serait un, difficile de dire si c'est la faute de la collation.

Surtout dans ce sens là d'ailleurs. Si c'était une valeur différente qui était égale d'après la collation, ce serait plus compréhensible (par exemple abc=ABC pour une collation case-insensitive). Mais deux valeurs réellement identiques à l'octet près dont la collation dit qu'elle sont différentes, là je ne vois pas bien quelle collation pourrait dirait ça. Une autre piste pourrait être plus simplement des caractères invisibles dans les valeurs, avec Unicode ça arrive. Dans ce cas, le fait qu'il y a une collation personnalisée serait une coïncidence.

Si la BDD est herbergée sur un serveur distant il faut mettre le nom ou l'adresse IP du serveur distant ici.

"localhost" en tant que nom réseau veut dire "en local" et est interprété du point de vue de celui qui se connecte. Quand vous dites au service looker studio de se connecter à localhost, vous lui dites de se connecter à lui-même en fait.