Vous n'êtes pas identifié(e).
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;Il y a une version en français ici:
https://blog-postgresql.verite.pro/2018 … pivot.html
Cette fonction dynamic_pivot() renvoie un curseur qu'il faut parcourir avec FETCH pour lire les résultats pivotés, comme montré dans l'exemple de l'article.
Dans votre cas en quoi ces résultats diffèrent des résultats attendus ?
\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
Table 9.20. Regular Expression Character-Entry Escapes
Escape Description
\a alert (bell) character, as in C
\b backspace, as in C
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.
Concernant l'ancien postgresql 13, tout a l'air OK: le package et l'unité systemd sont désinstallés.
Donc ça pose la question de savoir pourquoi ce message cité en #5 apparait
11:52 Assertion failed for postgresql@13-main.service - PostgreSQL Cluster 13-main.
11:52 postgresql@13-main.service: Starting requested but asserts failed."Starting requested" mais par quoi? Il doit rester une dépendance sur ce service quelque part.
Concernant les droits du user perso, le schéma en question est peut-être "public", et il se trouve que les permissions données à public ont été restreintes dans Postgres 15. Il faut maintenant donner les permissions explicitement aux utilisateurs en-dehors du possesseur de la BDD. En théorie lors d'un upgrade ce problème n'apparait pas car "public" est censé être migré avec ses permissions d'avant.
Et comment faire pour virer ce service qui traine concernant la version 13 ?
Il serait intéressant de voir ce que sortent ces commandes:
dpkg --get-selections 'postgres*'
systemctl list-units 'postgres*'Le fichier /var/lib/postgresql/15/main/postmaster.pid a un contenu du style:
1206
/var/lib/postgresql/15/main
1700725615
5432
/var/run/postgresql
localhost
11796503 0
ready où le nombre de la 1ere ligne est le numéro de processus PID que postmaster avait la dernière fois qu'il a tourné.
En cas d'arrêt normal ce fichier est effacé, en cas de reboot il ne peut pas l'être.
Dans votre cas, ce numéro de processus doit être maintenant constamment utilisé par un autre processus, sinon postgres effacerait le fichier et démarrerait quand même. C'est pourquoi il faut l'effacer à la main.
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" \
startLe 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.
lc_monetary influe sur l'affichage du type money (sachant que la plupart des applications n'utilisent pas ce type) et la sortie de la fonction to_char() pour le motif L, qui produit le symbole monétaire.
Peut-être que fr-CI ou fr_CI seraient acceptés comme nom de locale, mais ça reste à tester. Ces désignations ont l'avantage de ne pas avoir d'accent donc d'être compatible avec tous les encodages.
Au pire il est possible de spécifier "C" comme locale alternative qui devrait fonctionner dans tous les cas, mais qui est "neutre" c'est-à-dire que le symbole de monnaie sera une chaîne vide.
Ces locales alternatives peuvent être passées en option à initdb.
D'après la doc: https://docs.postgresql.fr/16/app-initdb.html
--locale=locale
Configure la locale par défaut pour le cluster. Si cette option n'est pas précisée, la locale est héritée de l'environnement d'exécution d'initdb.
Le support des locales est décrit dans Section 24.1.--lc-collate=locale
--lc-ctype=locale
--lc-messages=locale
--lc-monetary=locale
--lc-numeric=locale
--lc-time=localeMême principe que --locale, mais seule la locale de la catégorie considérée est configurée.
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)
Une ligne peut être de grande taille, sachant que la limite théorique d'une colonne de type text/json/jsonb/bytea etc.. est de 1 Go.
L'explication la plus simple au fait que la table croisse d'1,2 Mo par update est simplement que la ligne changée pèse 1,2 Mo.
On peut utiliser la fonction
SELECT pg_column_size(nom_colonne) FROM table WHERE ...pour voir les tailles réellement stockées par colonne (ça prend en compte la compression)
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.
La réponse est dans le commentaire #2 de cette discussion: il faut utiliser psql -U postgres
La différence se situe au niveau des caractères avec accent circonflexe
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.
pg_basebackup utilise le protocole de réplication, qui sollicite des règles à part dans le pg_hba.conf.
Pour activer l'authentification voulue, Il faudrait dans les lignes ci-dessous, remplacer scram-sha-256 par sspi map=MapForSSPI
host replication all 127.0.0.1/32 scram-sha-256
host replication all ::1/128 scram-sha-256Les 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.
Il y a une erreur d'inversion de a et b dans ce test:
(a IS NULL AND b IS NULL OR a > 0 AND b < 13 AND a > 22 AND b <= 99)Une fois l'erreur corrigée les résultats sont comme attendus.
Le AND est prioritaire par rapport à OR donc effectivement les parenthèses autour des expressions entourant le OR sont facultatives.
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.
L'erreur du pg_restore citée au 1er message est une violation de clef primaire qui suggère le DELETE FROM ma_table_à_restaurer a été fait dans une transaction non committée.
Le pg_restore se faisant dans une autre transaction, de son point de vue les données de ma_table_à_restaurer sont toujours là.
Pour faire marcher votre idée, il faudrait tout faire dans la même transaction, donc au lieu de jouer pg_restore directement sur la base il faut lui demander de créer un fichier avec les commandes SQL de restauration (option -f- de pg_restore) et ensuite passer ces commandes dans la même transaction que le reste (\i sous psql) après le DELETE et avant le COMMIT.
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.
On voit que cette collation non standard intervient dans la contrainte unique:
no_lot character varying(255) COLLATE public."numeric" NOT NULL,Quelle est la définition de cette collation?
Est-ce qu'une requête SELECT avec un GROUP BY sur les colonnes de la contrainte et HAVING count(*)>1 renvoie effectivement des lignes?
Nom de l'hôte: localhost (j'ai essayé 127.0.0.1)
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.
Il y a apparemment deux problèmes liés à GROUP BY dans cette requête.
1) Il faut utiliser WHERE et non pas HAVING pour filtrer les lignes de la table missions. L'utilisation de HAVING est réservée aux conditions qui s'appliquent aux résultats aggrégés avec GROUP BY.
2) le GROUP BY tranche semble ne pas avoir de sens puisque la tranche est elle même le résultat d'une aggrégation par semaine.
Si la requête est trop complexe il faut il y aller progressivement et la construire étage par étage en validant les étapes intermédiaires.
J'imagine que PostgreSQL est installé sur un poste Windows et que pgAdmin est lancé sur le même PC (pgAdmin et PostgreSQL sont deux logiciels distincts: pgAdmin est un client et PostgreSQL un serveur).
Par rapport à la copie d'écran dans le champ en haut Hostname/address if faut mettre localhost comme valeur.
Problème, des vues (au moins 1) m'a retourné une erreur :
elle utilise l'attribut consrc de pg_constraint de la 9.6 qui n'existe plus à partir de pg12.Est-ce que pg_upgrade de pg11 prend ce changement en considération et effectuera les changements ? Cela signifierait migrer de 9.6 vers 11, puis 11 vers 12 et enfin 12 vers 13 ?
Sinon, dois-je supprimer les vues en question avant et les recréer ensuite (post migration) ?
Non pg_upgrade ne peut pas gérer ça. La doc recommande d'utiliser la fonction pg_get_constraintdef() pour retrouver la définition d'une contrainte au lieu de la colonne consrc qui n'existe plus à partir de la version 12.
Le faire avant ou après la migration, c'est à vous de voir ce qui est le plus pratique pour vous.
Il y a des services web ouverts au public qui permettent de saisir du SQL dans une page web pour s'entraîner à faire des requêtes, mais généralement pas de s'authentifier via un client SQL. Par exemple sqlfiddle.com est assez connu mais il y en a d'autres.
Concernant les bases opendata, il y en a plein mais sous forme téléchargeable de fichiers SQL ou de fichiers CSV ou JSON, il faut les
charger dans son propre serveur.
Si vous avez installé PostgreSQL sur votre PC vous pouvez vous authentifier sur votre propre serveur et faire ce que vous voulez dessus.