Vous n'êtes pas identifié(e).
- Contributions : Récentes | Sans réponse
#1 Re : Général » Problème d'insertion dans une table » 07/01/2021 16:58:25
Pour ce que je comprends, vous avez une table fonction d'un côté qui préexiste (la question ne porte pas sur comment remplir cette table), avec une colonne "id" qui est une clef synthétique sans signification métier, et des colonnes
fonction_niv1
fonction_niv2
intitule_exact
statut
qui ont des significations métier.
D'un autre côté il y a un import dans une table agro avec 4 colonnes ci-dessous qui correspondent dans le même ordre:
inser_pro_fonction_niv1
inser_pro_fonction_niv2
inser_pro_fonction_intitule_exact
inser_pro_statut
sauf que cette correspondance peut être imparfaite, parce que sinon une jointure simple sur l'ensemble des colonnes fonctionnerait.
A mon sens si c'est bien la situation de départ, vous ne pouvez pas faire l'économie de décrire dans le détail, au niveau métier, ce qui est acceptable ou pas pour établir la correspondance entre une ligne à importer et les valeurs dans la table fonction.
C'est seulement une fois que l'analyse métier est faite, qui prend en compte tous les cas possibles, qu'on peut écrire le bout de SQL (LEFT JOIN ou autre) qui met en oeuvre cette analyse.
En l'occurrence les cas possibles semblent être des réponses oui/non aux quetsions "telle colonne est-elle remplie?" puisque si elle est remplie c'est une correspondance exacte sur la valeur qui va être attendue (je suppose).
Mais avec 4 colonnes ça fait quand même 2^4=16 combinaisons d'un côté de la jointure, 16 combinaisons de l'autre, soit 16x16=256 combinaisons possibles.
#2 Re : PL/pgSQL » update concatenation champ + row_number » 07/01/2021 16:22:35
Cette fonction et ce trigger ne me renvoi aucun message d'erreur mais le champ 'id_ouvrage' de la table 'ouv_protec_epci_ca_dracenoise' ne se rempli pas.
Votre trigger en message #17 fait ça:
NEW.id_ouvrage = NEW.bv||'_'||NEW.insee||'_'||(SELECT(count(*)+1)::text FROM ouvrage_v3.ouv_protec_epci_ca_dracenoise WHERE bv=NEW.bv and insee=NEW.insee and id_ouvrage=NEW.id_ouvrage);La partie
and id_ouvrage=NEW.id_ouvragen'a pas de sens puisqu'elle cherche une valeur qui n'est pas encore remplie. Regardez bien ce qu'a proposé Guillaume en #11, il n'y avait pas cette condition.
#3 Re : Général » Problème d'insertion dans une table » 04/01/2021 22:13:05
Parce que dans la comparaison NULL=quelquechose, NULL est absorbant, comme 0 dans la multiplication,
et que dans une combinaison logique expr1 AND expr2, NULL comme expression est aussi absorbant.
dit en SQL
test=> select ( true AND true AND 1=null ) is true;
?column?
----------
fConcrètement pour la jointure ça veut simplement dire que dans l'appariemment avec par exemple la table "fonction", si une des colonnes relatives à la fonction dans la table d'import est nulle, peu importe les autres colonnes, le résultat de l'appariemment avec LEFT JOIN est qu'il n'y aura pas de ligne trouvée dans fonction. Si c'est le résultat attendu, pas de problème.
#4 Re : Général » Problème d'insertion dans une table » 28/12/2020 20:09:42
Pour dire si le SQL est juste ou voir ce qui n'est pas juste, il faut revenir à l'expression ce que la requête doit faire.
Globalement on voit que la requête veut retrouver la ligne dans "fonction" qui satisferait ces conditions là:
f.fonction_niv1 = ag.inser_pro_fonction_niv1 AND f.fonction_niv2 = ag.inser_pro_fonction_niv2 AND f.intitule_exact = ag.inser_pro_fonction_intitule_exact AND f.statut = ag.inser_pro_statutsachant que "ag" désigne la table "agro" et f la table "fonction"
Et il y a la même logique pour la table employeur, avec ces conditions là:
ag.inser_pro_organisme_nom = emp.nom_organisme AND ag.inser_pro_type_employeur_niv1 = emp.type_employeur_niv1 AND ag.inser_pro_type_employeur_niv2 = emp.type_employeur_niv2 AND ag.inser_pro_taille_structure_niv1 = emp.taille_structure_niv1 AND ag.inser_pro_taille_structure_niv2 = emp.taille_structure_niv2Pour que cette logique fonctionne, il y a déjà des choses à vérifier:
- est-ce que certaines de ces colonnes dans agro peuvent être à NULL ou pas?
- si oui, est-ce que la colonne correspondante dans employeur ou fonction doit être NULL quand la colonne dans agro s'avère être à NULL? Autrement dit est-ce que NULL d'un côté et NULL de l'autre doit être considéré comme une égalité ou au contraire dès que l'un des côtés est NULL la correspondance ne doit pas être détectée?
Dans les réponses plus haut il est dit que dans la table employeur, une ligne ne peut pas être complètement nulle. Mais ce n'est pas la même question, parce que la condition de jointure ci-dessus est fausse dès qu'une seule colonne est à NULL.
- quand on a une correspondance sur toutes ces colonnes, quelle est la garantie qu'il y a une seule ligne qui correspond dans fonction (resp. employeur) ? Autrement dit est-ce qu'il y a un index unique (clef composite) sur l'ensemble de ces colonnes? S'il peut y avoir plusieurs lignes correspondantes, ça va poser un problème de multiplication des lignes à insérer.
#5 Re : Général » Problème d'insertion dans une table » 14/12/2020 20:12:04
Pour donner une opinion sur la requête, il faudrait comprendre pourquoi elle utilise ces FULL JOIN, qui sont utilisés rarement dans ce contexte.
Avec ce type de jointure, quand on teste si une colonne est NULL on ne sait pas si la colonne est absente et mise à NULL par le FULL JOIN ou si elle est présente mais que sa valeur est effectivement à NULL. A moins que toutes ces colonnes soient déclarées NOT NULL dans la source.
#6 Re : Général » Utilisation de PostgreSQL en mode NOsql » 23/11/2020 14:23:22
Pour les json, en revanche, de ce que je comprends en utilisant des champs de type jsonb, l'indexation est automatique, cela rentre dans le champ de ce que vous précisez ? ( à savoir une modification de structure fou tout en l'air)
Il ne fait aucun doute qu'entre json et jsonb dans le cas de cette question, il faut utiliser jsonb.
L'avantage de jsonb par rapport à json est qu'il est stocké pré-analysé, pré-découpé.
Mais l'indexation au sens où on l'entend en BDD (CREATE INDEX) n'est pas automatique avec jsonb.
Par exemple s'il y a une clef "nom" au premier niveau et que la recherche est WHERE champ_json->>'nom' = 'toto'
Postgres va tester chaque ligne de la table en parcours séquentiel, que le type soit json ou jsonb.
C'est seulement s'il y a un index explicitement créé sur champ_json->>'nom que la recherche va être vraiment accélérée.
Le souci dans cette question est que le niveau d'imbrication de la structure semble illimité. S'il fallait indexer des champs quelle soit leur profondeur dans la structure, je ne vois pas trop comment c'est possible.
#7 Re : Général » Utilisation de PostgreSQL en mode NOsql » 19/11/2020 15:21:14
Pour moi ce bout de doc a pour objet d'alerter sur 2 choses:
1) lorsqu'on écrit des requêtes qui exploitent des informations du json, on décrit forcément plus ou moins où trouver ces informations dans le json via les noms des clefs, les profondeurs de hiérarchie, et si on s'attend à trouver des tableaux ou des scalaires ou des objets et à quel niveau.
Et si on change notablement la structure json, ces requêtes ne fonctionnent plus, il faut les modifier.
Autrement dit, l'avantage de "flexibilité" du json doit être relativisé.
2) lors d'une modification d'un document JSON en base, la totalité du document est réécrite, quelque soit la taille de la modification. La seule manière de modifier un document est de soumettre la nouvelle version en intégralité.
#8 Re : Installation » Installation qui plante sans aucun message d'erreur ni explication » 19/11/2020 13:14:35
Le log de l'installeur est dans le répertoire temp de l'utilisateur qui le lance.
Cf https://wiki.postgresql.org/wiki/Troubl … r_log_file
Une alternative pour ne pas perdre trop de temps avec l'installeur est d'utiliser un ZIP des binaires déjà installés, qui sont dispos ici:
https://www.enterprisedb.com/download-p … l-binaries
Voir par exemple, pour un mini-tuto:
https://feilerdev.wordpress.com/2017/12 … installer/
Pour créer manuellement un service Windows pour démarrer automatiquement au boot, voir la commande pg_ctl register.
donc la doc est ici: https://www.postgresql.org/docs/current/app-pg-ctl.html
#9 Re : Général » reflexion sur serveur dédié le plus adéquat » 16/11/2020 17:24:17
Si vous regardez les specs chez Intel:
https://ark.intel.com/content/www/us/en … 0-ghz.html
https://ark.intel.com/content/www/fr/fr … 0-ghz.html
Le premier est clairement plus récent (2017 vs 2014, et architecture Skylake vs Haswell)
Si vous achetez un serveur neuf, l'archi Haswell déjà obsolète est un gros point négatif pour le e5-1650-v3.
Certes sa fréquence est supérieure, mais les accès mémoires et bus de l'autre seront plus rapides, outre le fait d'avoir plus de coeurs.
#10 Re : Réplication » replication physique sur postgresql 12 » 06/11/2020 21:32:24
La doc en français est sur un projet github: https://github.com/gleu/pgdocs_fr maintenu principalement par Guillaume.
La dernière version sur la branche principale a le bon nom de fonction pg_last_wal_receive_lsn (https://docs.postgresql.fr/13/functions-admin.html) mais effectivement quelques versions précédentes sont passées à côté du renommage.
Vous pouvez bien sûr signaler des erreurs de traduction via github et soumettre des corrections sous forme de Pull Request.
#11 Re : Installation » Création d'une connexion PostGIS depuis Quantum GIS » 12/10/2020 16:12:40
Le problème vient peut être du réseau de l'école qui doit être trop sécurisé pour ce type d'utilisation ?
Oui, à moins d'avoir l'information que les connexions Internet sont autorisées sur ce poste depuis l'extérieur, vous pouvez partir du principe qu'elles sont bloquées, par un pare-feu en amont auquel vous n'avez pas accès. C'est l'inverse qui serait étonnant.
#12 Re : Général » CTE PostgreSQL 12.3 » 30/09/2020 13:56:20
Non il n'y a pas d'option pour matérialiser systématiquement avec la clause WITH.
Il faut ajouter MATERIALIZED soi-même si nécessaire, mais ça parait très pessimiste de prévoir de faire ça sur toutes les CTEs.
Si cette évolution a été faite dans Pg12, c'est justement parce que la matérialisation systématique ne convient pas à toutes les requêtes.
#13 Re : Général » [inconnu]@[inconnu] LOG: paquet de démarrage incomplet » 15/09/2020 15:54:26
Le lien entre systemd et pg_ctlcluster est exprimé dans le fichier /lib/systemd/system/postgresql@.service:
[Unit]
Description=PostgreSQL Cluster %i
AssertPathExists=/etc/postgresql/%I/postgresql.conf
RequiresMountsFor=/etc/postgresql/%I /var/lib/postgresql/%I
PartOf=postgresql.service
ReloadPropagatedFrom=postgresql.service
Before=postgresql.service
# stop server before networking goes down on shutdown
After=network.target
[Service]
Type=forking
# -: ignore startup failure (recovery might take arbitrarily long)
# the actual pg_ctl timeout is configured in pg_ctl.conf
ExecStart=-/usr/bin/pg_ctlcluster --skip-systemctl-redirect %i start
# 0 is the same as infinity, but "infinity" needs systemd 229
TimeoutStartSec=0
ExecStop=/usr/bin/pg_ctlcluster --skip-systemctl-redirect -m fast %i stop
TimeoutStopSec=1h
ExecReload=/usr/bin/pg_ctlcluster --skip-systemctl-redirect %i reload
PIDFile=/run/postgresql/%i.pid
SyslogIdentifier=postgresql@%i
# prevent OOM killer from choosing the postmaster (individual backends will
# reset the score to 0)
OOMScoreAdjust=-900
# restarting automatically will prevent "pg_ctlcluster ... stop" from working,
# so we disable it here. Also, the postmaster will restart by itself on most
# problems anyway, so it is questionable if one wants to enable external
# automatic restarts.
#Restart=on-failure
# (This should make pg_ctlcluster stop work, but doesn't:)
#RestartPreventExitStatus=SIGINT SIGTERM
[Install]
WantedBy=multi-user.target#14 Re : Site PostgreSQL.fr » Passer NEW en paramètre d'une procédure » 14/09/2020 17:35:44
Je ne comprends pas la raison de l'erreur, mais utilisez plutôt une fonction plutôt qu'une procédure pour autogen_audit. L'intérêt des procédures est de pouvoir faire du contrôle de transaction mais ici ça n'est pas pertinent.
Si autogen_audit était une fonction, la fonction appelante ferait
NEW := autogen_audit(NEW, TG_OP);et ça devrait fonctionner.
#15 Re : Général » [inconnu]@[inconnu] LOG: paquet de démarrage incomplet » 14/09/2020 15:45:00
Certains scripts de démarrage produisent cette erreur systématiquement en testant si le serveur est bien accessible.
Par exemple sur Debian/Ubuntu la commande pg_ctlcluster appelée par le script systemd va appeler cette fonction
(en Perl) après avoir lancé le serveur:
# Check whether a postgres server is running at the specified port.
# Arguments: <version> <cluster> <port>
sub cluster_port_running {
die "port_running: invalid port $_[2]" if $_[2] !~ /\d+/;
my $socketdir = get_cluster_socketdir $_[0], $_[1];
my $socketpath = "$socketdir/.s.PGSQL.$_[2]";
return 0 unless -S $socketpath;
socket(SRV, PF_UNIX, SOCK_STREAM, 0) or die "socket: $!";
my $running = connect(SRV, sockaddr_un($socketpath));
close SRV;
return $running ? 1 : 0;
}Cette fonction tente d'ouvrir une connexion et si ça marche, la ferme immédiatement, le but étant juste de savoir si ça répond ou pas. Que postgres logge l'erreur "paquet de démarrage incomplet" est un effet de bord de ce test.
#16 Re : Général » Apprenti PostgreSQL étudiant la haute disponibilité/réplication » 07/09/2020 16:35:35
creating directory /Library/PostgreSQL/11/tstrepl1prim ... initdb: could not create directory "/Library/PostgreSQL/11/tstrepl1prim": Permission denied
Dans mes diverses recherches, la seule "solution" évoquée consistait à donner les droits root à Postgres (via sudoers), ce qui n'est bien entendu pas envisageable en terme de sécurité.
Mais ce n'est pas nécessaire.
On peut créer à l'avance le répertoire de données, et l'attribuer à l'utilisateur postgres, c.a.d:
$ sudo mkdir /Library/PostgreSQL/11/tstrepl1prim
$ sudo chown postgres /Library/PostgreSQL/11/tstrepl1primC'est suffisant à initdb pour pouvoir travailler et écrire dans ce répertoire en tant que postgres.
#17 Re : Général » \copy : erreur "Aucun fichier ou dossier de ce type" » 17/07/2020 15:08:00
Je pense que vous lancez ce scp sur le serveur, en tant que commande linux à l'intérieur de votre session putty, alors qu'il faut le lancer sur le PC Windows en tant que commande Windows.
#18 Re : Général » \copy : erreur "Aucun fichier ou dossier de ce type" » 17/07/2020 14:25:48
Pour transférer le fichier vers un PC windows il faut utiliser un programme de transfert qui fonctionne avec le protocole SSH.
Il y en a pas mal, par exemple: WinSCP ou BitVise qui ont des interfaces graphiques, ou en ligne de commande pscp.exe ou psftp.exe (ceux-là sont téléchargeables sur le même site que putty)
#19 Re : Général » \copy : erreur "Aucun fichier ou dossier de ce type" » 17/07/2020 12:23:59
4. je lance la commande \copy matable TO '/home/path/to/my/file/file.txt' et j'obtiens le message d'erreur suivant : '/home/path/to/my/file/file.txt' : Permission non accordée
A la place de '/home/path/to/my/file/file.txt' il faut mettre un chemin où l'utilisateur "postgres" de votre serveur a le droit d'écrire.
Généralement un utilisateur a au moins le droit d'écrire dans son répertoire personnel.
Pour savoir quel est le répertoire personnel de postgres, au lieu de faire sudo -u postgres psql, vous pouvez faire
sudo -u postgres -iCe donnera un shell interactif. Puis exécuter
pwdpour savoir quel est le répertoire courant, ou bien
echo $HOME qui devrait donner le même résultat.
Ensuite faire
psqltout seul (sans sudo) et utiliser ce répertoire pour la destination de \copy.
#20 Re : Sécurité » PostgreSQL 11.6 - problème connexions IPV6-IPV4 - pg_hba.conf » 10/07/2020 10:32:39
Si je n'ai pas cette ligne dans mon fichier pg_hba.conf. Je peux me connecter via l'interface Firefox au serveur Pgadmin (saisie du mot de passe) par contre au niveau de l'ouverture PostgreSQL 11, il bloque sur le mot de passe.
Vraisemblablement le PC résoud localhost en ::1 (IPv6) et donc il faut cette règle dans le pg_hba.conf. Vous n'avez pas besoin de choisir entre 127.0.0.1/32 et ::1/128, on peut mettre les deux règles. D'ailleurs je crois que la config par défaut a les deux.
#21 Re : Général » Importation des données volumineuses. » 10/07/2020 10:24:46
Il y a un bug connu là-dessus de Postgres 11/12 sur Windows, cf https://www.postgresql.org/message-id/1 … gresql.org
Malheureusement je crois que la solution n'est toujours pas disponible.
Il faut couper le fichier en plus petits segments ou peut-être le passer sous forme de flux par la clause PROGRAM.
#22 Re : Sécurité » standby ssl certificate » 09/07/2020 12:36:13
Pour moi elle sera chiffrée du fait de sslmode=require.
Je ne suis pas sûr que sslrootcert=/var/lib/pgsql/.postgresql/root.crt serve à quelque chose dans ce cas de figure.
#23 Re : Sécurité » PostgreSQL 11.6 - problème connexions IPV6-IPV4 - pg_hba.conf » 07/07/2020 17:55:41
Il est clair que la colonne des adresses est mal remplie.
Regardez ce qu'il y a dans les blocs d'adresse d'exemple ici (chercher CIDR):
https://fr.wikipedia.org/wiki/Adresse_IP
Si les astérisques '*' derrière les fe80:: sont là pour cacher vos adresses IPv6, ne vous embêtez pas avec ça, fe80::/64 sont des adresses locales, personne de l'extérieur ne pourra tenter de se connecter dessus.
Pour les CIDR IPv4 du genre 1**.***.0/50 et 1**.***.0.50/131, le dernier nombre doit être compris entre 0 et 32.
#24 Re : Sécurité » standby ssl certificate » 06/07/2020 12:17:46
Il n'y a pas besoin de certificat côté client pour chiffrer la communication, on peut se contenter de sslmode=require dans la chaîne de connexion.
par défaut c'est sslmode=prefer, c'est-à-dire qu'il essaie avec SSL puis si ça ne marche pas, sans SSL. C'est pourquoi on trouve ce "SSL off" dans le message d'erreur:
FATAL: could not connect to the primary server: FATAL: client certificates can only be checked if a root certificate store is available
FATAL: no pg_hba.conf entry for replication connection from host "10.12.51.122", user "postgres", SSL off
#25 Re : Sécurité » SSL - besoin d'explications » 28/06/2020 20:50:55
La déclaration ci-dessous a un problème de syntaxe:
hostssl db usr 192.168.0.1/16 clientcert=verify-caLe modèle de syntaxe est
# hostssl DATABASE USER ADDRESS METHOD [OPTIONS]et clientcert=verify-ca est une option, pas une méthode d'authentification.
Il faut donc ajouter un choix d'authentification dans la colonne METHOD.
Par ailleurs quand on utilise clientcert=verify-ca, c'est pour que le serveur vérifie le certificat du client, qui par défaut est
fourni dans ~/.postgresql/postgresql.crt
Or dans la question il ne semble pas que ce soit le cas, il semble que vous mettiez en oeuvre le test
inverse qui consiste à ce que le client vérifie qu'il parle bien avec le bon serveur via le certificat
(~/.postgresql/root.crt par défaut)
Ce qu'il faut fournir dans les deux cas est décrit par https://www.postgresql.org/docs/current/libpq-ssl.html
dans "Client Verification of Server Certificates" et "Client Certificates".