PostgreSQL La base de donnees la plus sophistiquee au monde.

Forums PostgreSQL.fr

Le forum officiel de la communauté francophone de PostgreSQL

Vous n'êtes pas identifié(e).

#1 Re : Général » Comparaison taille table/colonne INTEGER ET VARCHAR » 26/06/2020 11:16:57

C'est normal. Il y a des "frais fixes" pour un enregistrement dans les bases de données. On a un entête de bloc de taille fixe, et un entête d'enregistrement, de taille fixe aussi. C'est bien détaillé ici: https://www.postgresql.org/docs/current … ayout.html

L'entête de bloc est souvent négligeable. L'entête d'enregistrement beaucoup moins… c'est 23 octets sous Postgres.

#2 Re : PL/pgSQL » Détecter différents formats de date » 19/06/2020 11:22:30

Vous avez certainement intérêt à utiliser du pattern matching, avec des expressions régulières par exemple: https://www.postgresql.org/docs/12/func … SIX-REGEXP

#3 Re : Sécurité » Droit refusé sur une vue » 08/06/2020 16:40:53

Ok. Un dernier piège… un utilisateur pourrait tenter, par la vue, de changer id_reseau ¸ res_noeud.type_noeud ou res_noeud.date_suppression IS NULL. Et donc faire "disparaître" des données de la vue. Il vaudrait probablement mieux se prémunir de ça dans la fonction PL (un contrôle sur les insert/update dès le départ je pense)

#4 Re : Sécurité » Droit refusé sur une vue » 08/06/2020 15:22:36

Non, ça doit le faire, il faut que l'utilisateur propriétaire de la fonction trigger soit autorisé à manipuler les tables en dessous, mais pas l'utliisateur qui travaille sur les vues. Lui devrait juste avoir des droits sur la vue. Ça ne marche pas ?

#6 Re : Sécurité » Droit refusé sur une vue » 08/06/2020 10:08:06

La raison pour se protéger du search_path, c'est que c'est une variable de session. Donc si vous ne la forcez pas dans la fonction, un utilisateur mal intentionné pourra remplacer son search_path et essayer d'exploiter les noms d'objets sans schéma dans votre fonction, avec les droits améliorés de la fonction, vu qu'elle est security definer.

#7 Re : Sécurité » Droit refusé sur une vue » 08/06/2020 10:06:56

C'est exactement ce que dit la doc. Quand on fait une fonction security definer, il faut mettre un search_path restrictif (idéalement, uniquement pg_catalog, si on veut vraiment être sûr), et préfixer tous les objets auxquels on accède par leur schéma pour être vraiment explicite. Vu que c'est déjà presque bon dans votre fonction (currval('res_noeud_id_noeud_seq'::regclass) par exemple ne précise pas le schéma, il faudra le corriger), il suffit de modifier l'entête de la fonction par :

CREATE OR REPLACE FUNCTION res_eau_vanne_vue_edit()
RETURNS trigger SECURITY DEFINER SET search_path= '' AS

ou quelque chose de très approchant.

Vous pouvez le mettre avant ou après le bloc AS, ça n'a aucune importance.

Une fois que vous aurez fait ça, la fonction s'exécutera en tant que son propriétaire, et non plus en tant que l'utilisateur appelant. Faites donc bien attention à ce qu'elle appartienne à un utilisateur (role) ayant accès aux objets en question en écriture.

Si l'utilisateur n'est pas bon, vous pouvez faire un ALTER FUNCTION ... OWNER TO.

Et il faudra peut-être faire un GRANT EXECUTE sur cette fonction aux utilisateurs ayant accès à la vue (par défaut ça devrait être bon).

#8 Re : Sécurité » Droit refusé sur une vue » 08/06/2020 09:38:30

Pour le search_path vous faites référence à la doc de security definer qui vous recommande de mettre un search_path en dur ?

#9 Re : Sécurité » Droit refusé sur une vue » 05/06/2020 17:51:35

Je pense que le paragraphe que vous tirez de la doc, c'est pour les vues qui ne nécessitent pas de trigger instead of. Le trigger, lui, il exécute la fonction en tant que la personne connectée. À mon avis, si vous définissez la fonction comme security definer, avec comme propriétaire grp_aep_admin, ça marchera, puisque la fonction s'exécutera en tant que grp_aep_admin

#10 Re : Général » pgBackRest - ERROR: [070] » 03/06/2020 17:16:53

ça sent le portage 1:1 d'Oracle, c'est une pratique habituelle, séparer les data et les index dans des schémas différents

#11 Re : Général » pgBackRest - ERROR: [070] » 03/06/2020 15:25:25

Le répertoire cible d'un tablespace ne devrait pas être dans le PGDATA. Sinon vous courrez le risque de le backuper deux fois, d'avoir le système de backup qui écrase les mauvais fichiers, etc… c'est pour ça que pgbackrest refuse de backuper. Mieux vaut vous alerter maintenant.

À moins que axidata soit un point de montage vers un autre filesystem, ce tablespace n'a aucun intérêt pour postgres de toutes façons, le but d'un tablespace sous postgres, c'est juste de pouvoir utiliser un système de fichiers différent (sur un type de stockage différent par exemple) pour certains objets. Donc deux possibilités pour résoudre votre problème:
- soit axidata est un point de montage. Dans ce cas là, arrêtez l'instance, remontez le ailleurs, qui ne soit pas un sous répertoire de /axihome/base2/postgresdata/, et mettez à jour le lien symbolique (techniquement le tablespace n'est qu'un lien symbolique) de 'pg_tblspc/16432 pour pointer vers la nouvelle destination
- soit c'est juste un répertoire. dans ce cas, il ne sert vraiment à rien, vous allez plus vous compliquer la vie qu'autre chose. ramenez les objets dans le tablespace par défaut, supprimez le tablespace. ça a un sens sous oracle par exemple, parce qu'il gère des datafiles, sous postgres ça ne sert à rien.

#12 Re : Général » Conversion d'une chaine numérique vers un type oid » 29/04/2020 08:25:15

ou même vous débarasser de to_number...

postgres=# select 123456::oid;
  oid   
--------
 123456
(1 row)

Si vraiment vous avez besoin de partir d'une chaîne, vous pouvez aussi vous contenter de ça, postgres va deviner tout seul quoi faire:

postgres=# select '123456'::oid;
  oid   
--------
 123456
(1 row)

Les types numeric ne sont pas castables en oid par contre.

#13 Re : Réplication » Erreur Pgpol-II » 07/04/2020 09:51:46

+1. Avec pgpool, ça ne marchera pas. On a déjà essayé smile

#14 Re : Réplication » Erreur Pgpol-II » 07/04/2020 09:27:05

Ça dépend du problème à résoudre. C'est le côté "couteau suisse" de pgpool. Vous l'avez installé pour résoudre quel problème ?

#15 Re : Réplication » Erreur Pgpol-II » 07/04/2020 08:17:59

Aucune idée de la cause de votre problème. Par contre, je peux vous donner un conseil: virez pgpool. C'est mauvais pour la haute dispo, la répartition de charge et la réplication. Entre les bugs et la perte de performance, il n'y a vraiment aucun cas d'utilisation valable. Quel que soit votre cas d'utilisation, il y a mieux que pgpool (à peu près tout ce que vous pourrez trouver).

#16 Re : Général » Ecriture dans tablespace specifique » 03/03/2020 10:57:40

Le mieux serait de commencer par regarder dans le fichier de log postgres si vous avez un message d'erreur…

#17 Re : PL/pgSQL » jointures sql entre 3 tables » 19/02/2020 14:16:32

Un truc de ce genre ?

select p.pays, f.film from bx.film_id = f.id cross join pays p where not exists (select 1 from box_offices bx where bx.film_id = f.id and bx.pays_id = p.id) 

#18 Re : Général » Fichiers tmp.QHoZCixFte (tmp.zorglub) créées par Postgrès dans /tmp » 17/02/2020 19:08:08

Bonjour,

Le format de nommage de ces fichiers ressemble plutôt à ce que produit la commande "mktemp", pas à ce que produirait postgresql. Vous avez probablement un script quelque part qui crée ces répertoires.

#19 Re : Général » Clé primaire ET clé étrangère ? » 06/02/2020 21:06:57

J'ai l'impression d'un quiproquo...

Je pense que la phrase voulait dire les identifiants (ID) peuvent être identiques entre les deux tables.

Dans ce cas, aucune impossibilité à avoir ID en PK sur les deux tables, et en FK référençant l'autre table. La seule difficulté en faisant ça, c'est de réussir à insérer des données (mettre les contraintes en deferrable initially deferred par exemple).

Par contre, une FK ce n'est pas "peuvent être identiques", mais "doivent être identiques". Si une table peut contenir des id qui ne sont pas dans l'autre, il n'y a plus de lien de FK dans ce sens.

#20 Re : pgAdmin4 » Erreur accès au serveur » 27/01/2020 11:50:09

Bonjour,
Aucune idée, Azure Database for PostgreSQL est un service propriétaire de Microsoft. Pourquoi ne vous adressez-vous pas à eux ?

#21 Re : Général » fonction avec récupération current_user et current timestamp » 24/01/2020 10:35:19

Il faut deux fonctions, appelées par deux triggers différents.

La doc est là : https://www.postgresql.org/docs/10/trig … ition.html . Ce n'est pas extrêmement synthétique, mais ce n'est pas un sujet très simple non plus smile

#22 Re : Général » fonction avec récupération current_user et current timestamp » 23/01/2020 19:05:57

L'explication la plus simple que je vois: vous avez déclaré le trigger comme "AFTER". Si ce n'était pas le cas vous auriez des erreurs sur les INSERT. Par contre, pour pouvoir modifier NEW, il faut un trigger BEFORE. Donc je pense que vu ce que vous voulez faire, c'est un trigger BEFORE qui modifie NEW, et un trigger AFTER qui fait les insert.

#23 Re : Général » Message d'erreur à création d'index » 25/11/2019 12:03:11

J'imagine que ce n'est pas 40 caractères (soit maximum 160 octets en utf8), mais une faute de frappe ?

Pour le fichier CSV, vous êtes sûr d'avoir vérifié l'intégralité des lignes ?
Les caractères non-ascii ne posent pas de problème, tant que l'encodage de votre fichier est le même que celui de la session (ou que vous avez passé l'encoding à COPY). Vous pouvez voir l'encoding de la session avec SHOW client_encoding... aucune idée de ce que fait pgadmin4 de ce point de vue...

#24 Re : Général » Message d'erreur à création d'index » 24/11/2019 18:37:19

"ERREUR: la ligne index requiert 1298240 octets, la taille maximum est 8191".

=> Vous avez des champs trop gros pour être indexés. J'imagine que c'est une chaîne de caractères que vous essayez d'indexer ? Si oui, il y a une limite (elle est même plus basse en fait). On a quelques moyens de contournement, mais c'est à voir dans un second temps.

D'autre part à partir d'une table vide sans index quand j'ai voulu importer un fichier .csv avec 2 902 593 lignes il a été importer que 1 554 138 lignes sans message d'erreur , bizarre non .

Non, pas forcément, on peut très bien avoir des retours de chariots dans un CSV. Un enregistrement de ce genre par exemple:

1;"bonjour
les copains"
2;toto

3 lignes, 2 enregistrements.

Pied de page des forums

Propulsé par FluxBB