Messages de Alain V.

Alain V. · Général

damalaan a écrit :

bonjour,
Est-ce vraiment utile de stocker un élément calculé ?

Bonjour,
Non, ce n'est pas vraiment utile.
C'est un script Bash déclenché par une tâche Cron qui va chercher cet élément.
Il est mis dans une page html qui est envoyée par email.

SELECT "date", releve,
releve - lag(releve, 1) OVER (PARTITION BY 1 ORDER BY "date") as parcouru

Voilà une structure de requête que je n'avais jamais vue!

damalaan a écrit :

et du coup plus besoin de la colonne parcouru dans la table.

C'est exact. Je confirme.
J'ai mis la requête dans une vue. Le script Bash va pouvoir trouver l'élément calculé qu'il a besoin.

Du coup, à part un copié/collé de la requête, je n'ai rien eu à faire.
En postant ici, je n'en demandais pas tant!
Merci beaucoup!
Je reste émerveillé devant cette requête qui fourni un élément calculé.
Je vais l'étudier de près.

Alain V. · Général

Je vais donc me mettre aux fonctions.
Merci de m'avoir mis sur la bonne voie car je n'en étais pas sûr.

Alain V. · Général

Merci pour ce retour.
1)
Pour calculer la valeur de la colonne (parcouru) je pense qu'il faut identifier la date la plus récente puis celle immédiatement avant. Je devrais m'en sortir plus ou moins élégamment.

2)
Par contre il n'y a pas à insérer de ligne puisqu'il s'agit d'un UPDATE du champ (parcouru).
C'est là que je butte : comment updater automatiquement ce champ si une valeur de la colonne (releve) est modifiée.

Alain V. · Général

Bonjour le forum,

J'imagine que cela doit être aussi simple avec Postgresql qu'avec un tableur mais je ne sais pas par quel bout commencer car je n'ai jamais fait de calculs à partir de champs disposés dans deux tuples.

Mon but c'est de faire un UPDATE sur la colonne (parcouru).
La méthode de calcul est très simple puisqu'il ne s'agit que de faire une différence de relevés entre deux dates consécutives.

CREATE TABLE comptage(
        date date UNIQUE,
        releve numeric(9,0),
        parcouru numeric(9,0)
);
COPY comptage(date,releve) FROM stdin;
2015-12-22      7
2001-01-01      2
2016-09-22      10
\.

Dans la table, les enregistrements n'arrivent pas systématiquement dans l'ordre chronologique de la colonne (date).
Si une valeur (releve) est modifiée ultérieurement, la colonne (parcouru) devra être automatiquement "updatée".

Au final, voici ce que je veux obtenir :

COPY comptage(date,releve,parcouru) FROM stdin;
2015-12-22      7       5
2001-01-01      2       0
2016-09-22      10      3
\.

Je butte sur la mise à jour permanente de la colonne (parcouru) entre deux dates de relevés consécutifs.
Est-ce que la solution c'est de faire appel à une fonction? Je ne les ai encore jamais abordées.
Pour surveiller ma table, j'ai trouvé quelque chose qui me semble être un point de départ ici:
http://forums.postgresql.fr/viewtopic.php?id=3866

Merci par avance de m'indiquer comment on traite d'habitude ce genre de problème.

Alain V. · Général

En effet, maintenant le format est de longueur fixe :

CREATE VIEW mavue AS
SELECT to_char (chrono::time,'HH24:MI:SS.MS') AS chrono
FROM matable;

chrono
--------------
00:00:42.000
00:00:42.150

Ce ne me sera pas trop difficile que de supprimer ce zéro de queue en trop pour avoir des centièmes de secondes.

Merci beaucoup pour la réponse.

Alain V. · Général

Bonjour le forum,

Je souhaite afficher un chronométrage sous ce format :
00:00:42.15

CREATE TABLE matable (chrono time without time zone);
COPY matable (chrono) FROM STDIN;
00:00:42.00
00:00:42.15
\.
CREATE VIEW mavue AS SELECT * FROM matable;

Le résultat de la requête fait que les zéros de queue non significatifs
sont supprimés:
chrono
00:00:42
00:00:42.15
Je souhaite conserver ces zéros non significatifs car derrière, il y a
un script bash qui récupère la vue. Celui-ci travaille sur la longueur
de la chaîne et je ne souhaite pas le modifier.

En précisant le 100è de seconde dans la table,

CREATE TABLE matable (chrono time (2) without time zone);

comme le résultat est le même j'ai pensé chercher dans les fonctions de
formatage :
http://docs.postgresql.fr/8.2/functions … ting-table
On y parle de "to_char(timestamp, text)" alors que dans ma table ce
serait peut-être un "time --> texte"

Est-ce que je fais fausse route où y a-t-il une autre façon de ne pas
perdre ces zéros de queue dans la table?

Merci par avance.

Alain V. · Général

Merci beaucoup pour votre réponse.

Comme je ne souhaite pas utiliser les backports, cela implique que je doit aligner toutes mes Debian qui communiquent avec Postgres.

Alain V. · Général

Si le dump est exécuté localement par l'utilisateur sur sa base alors il n'y a aucun message d'erreur.

$ pg_dump > dump.sql
Mot de passe :
$

Alain V. · Général

Bonjour le forum.

Mon niveau est juste "basique" avec Postgres et tout est dans le titre.

Comme je viens de créer une nouvelle base de données, avant de la remplir, je commence par mettre en place sa sauvegarde ;-)
Je découvre immédiatement ceci :

$ pg_dump -i -D -h 192.168.1.4 -U archimede archimede > dump.sql
Mot de passe :

pg_dump: version du serveur : 8.4.5 ; pg_dump version : 8.3.13
pg_dump: traitement malgré la différence des versions
pg_dump: la commande SQL a échoué
pg_dump: Message d'erreur du serveur : ERREUR:  la colonne « reltriggers » n'existe pas
LINE 1: ...oles WHERE oid = relowner) as rolname, relchecks, reltrigger...
                                                             ^
pg_dump: La commande était : SELECT c.tableoid, c.oid, relname, relacl, relkind, relnamespace, (SELECT rolname FROM pg_catalog.pg_roles WHERE oid = relowner) as rolname, relchecks, reltriggers, relhasindex, relhasrules, relhasoids, d.refobjid as owning_tab, d.refobjsubid as owning_col, (SELECT spcname FROM pg_tablespace t WHERE t.oid = c.reltablespace) AS reltablespace, array_to_string(c.reloptions, ', ') as reloptions from pg_class c left join pg_depend d on (c.relkind = 'S' and d.classid = c.tableoid and d.objid = c.oid and d.objsubid = 0 and d.refclassid = c.tableoid and d.deptype = 'a') where relkind in ('r', 'S', 'v', 'c') order by c.oid

Le client est en 8.3 sur une Lenny. Il parle avec :
- un serveur en 8.3 sur une Lenny
- un serveur en 8.4 sur une Squeeze. D'où le "-i" du pg_dump ci-dessus.

Le serveur 8.4, n'est pas sur le même brin de réseau que le client.
Le client peut s'y connecter sans problème.

En cherchant profondément dans ce fil :
http://listes.postgresql.fr/pipermail/t … 00490.html
je crois comprendre qu'il s'agit d'un problème de compatibilité entre les versions avec Slonik.

...
-<li>Change default $LOGDIR, so that distros won't need to patch it.
+  <li> pg_class.reltriggers n'existe plus dans 8.4 et donc ne doit plus être touché
...

Si Slonik a été installé, cela a dû être fait automatiquement avec les autres paquets lors de l'aptitude instal...

Il me semble comprendre que les "ubuntéros" avaient réglé un bug :
http://www.mail-archive.com/universe-bu … 61330.html
Est-ce que ça concerne aussi mon cas sous Debian?

J'ai trouvé une autre situation similaire ici:
http://forums.postgresql.fr/viewtopic.php?id=742
Par contre, contrairement à ce dernier cas, moi, je n'ai pas touché aux tables systèmes. Vu mon niveau, je ne m'y aventure pas.
Comme je viens juste d'installer Postgres sur cette nouvelle machine je n'ai fait que de créer/droper des utilisateurs et des bases sous Postgres, des bases, des tables et des vues sous des utilisateurs différents.

Voici la base qui refuse de se laisser dumper :

$ psql -h 192.168.1.4 -U archimede archimede
Mot de passe :
Bienvenue dans psql 8.3.13 (serveur 8.4.5), l'interface interactive de PostgreSQL.

Saisissez:
    \copyright pour les termes de distribution
    \h pour l'aide-mémoire des commandes SQL
    \? pour l'aide-mémoire des commandes psql
    \g ou point-virgule en fin d'instruction pour exécuter la requête
    \q pour quitter

ATTENTION : vous êtes connecté sur un serveur dont la version majeure est
8.4 alors que votre client psql est en version majeure 8.3. Certaines
commandes avec antislashs, comme \d, peuvent ne pas fonctionner
correctement.

Connexion SSL (chiffrement : DHE-RSA-AES256-SHA, bits : 256)

archimede=> \d
                 Liste des relations
 Schéma |        Nom        |   Type   | Propriétaire
--------+-------------------+----------+--------------
 public | table1            | table    | archimede
 public | table1_champ1_seq | séquence | archimede
 public | view1             | vue      | archimede
 public | view2             | vue      | archimede
(4 lignes)

archimede=> SELECT * FROM table1;
 champ1 | champ2
--------+---------
      1 | Ligne1
      2 | Ligne2
      3 | Ligne3
      4 | Ligne4
      5 | Ligne5
      6 | Ligne6
      7 | Ligne7
      8 | Ligne8
      9 | Ligne9
     10 | Ligne10
(10 lignes)

archimede=> \d table1
ERREUR:  la colonne « reltriggers » n'existe pas
LINE 1: SELECT relhasindex, relkind, relchecks, reltriggers, relhasr...

J'avais créé la table ainsi :

CREATE TABLE table1 (champ1 serial, champ2 varchar(30));

Je pourrais mettre ça sur le dos du "\d" qui pourrait ne pas fonctionner correctement mais cela ne tient pas pour pg_dump.

Bref, je fais du ping pong entre un message relatif à reltriggers et celui d'un serveur qui n'accepte que difficilement une compatibilité descendante avec un client.

Est-ce que quelqu'un aurait une idée dans quelles directions devrais-je plutot orienter mes recherches?

Merci par avance.

Alain V. · Général

Je vais continuer à chercher. Peut-être vais-trouver un objet identifiant ou une méthode pour gérer de simples numéros que moi je baptise : identifiants et pour lesquels l'objet séquence de Postgres ne me sert qu'à me faciliter la création au sein d'une progression arithmétique.

Merci beaucoup à vous deux. Je garde vos idées.

Alain V. · Général

gleu a écrit :

Pourquoi avez-vous besoin d'interdire la réutilisation d'un identifiant issue d'une séquence ? les séquences ne sont pas faites pour ça en fait.

Je veux interdire la réutilisation d'un identifiant qu'il soit issu d'une séquence ou de n'importe quelle autre méthode.
La séquence ne m'est utile que pour me simplifier la création d'identifiants structurés.

Exemple d'utilisation :
- Un badge numéroté est délivré à l'entrée d'un parking. Il est détruit à la sortie. Son identifiant ne doit plus jamais être créé sinon on faussera le traçage de ce badge.

Peut-être que ma question est mal formulée.
Il y a l'idée de mettre l'identiant dans une autre table. On peut aussi ajouter une colonne qui indique l'état détruit ou pas. Mais je ne sais pas comment supprimer le risque de l'insert d'identifiants hors séquence.

Alain V. · Général

Bonjour le forum,

Une séquence avec incréments me facilite la création d'identifiants incrémentés.

CREATE SEQUENCE masequence START 10 INCREMENT BY 10;

CREATE TABLE matable (
noid int4 DEFAULT nextval('masequence') UNIQUE,
colonne char(4)
);

Mais je ne sais pas assurer une protection contre ce genre d'insertion hors incréments;

INSERT INTO matable (noid, colonne) VALUES (3,3);

Il est aussi possible de réutiliser un identifiant identique à celui d'un autre ayant été précédemment détruit.

SELECT noid, colonne FROM matable WHERE noid=3;

 noid | colonne
------+---------
    3 | 3

DELETE FROM matable WHERE noid=3;
INSERT INTO matable (noid, colonne) VALUES (3,0);

Comment interdire ces deux possibiilités :
- je veux interdire l'utilisation d'un identifiant qui n'est pas dans la progression de la séquence
- je veux interdire de recréer un identifiant ayant déjà été détruit

Dans mon apprentissage de Postgres je n'ai pas encore abordé les fonctions ni d'autres outils plus élaborés.
Est-ce dans cette direction que je dois chercher?

Merci par avance pour vos conseils.

Alain V. · Sécurité

Merci pour tous ces points.
Je vais installer pgadmin pour car actuellement je n'utilise que phppgadmin.

Alain V. · Sécurité

Bonjour le forum,

Je cherche à m'organiser pour les sauvegardes des données et pour les structures des bases.
Vu ce que j'ai déjà lu, je comprends que je gère de très petites bases de données.

Je sais sauvegarder les tables, les bases, les données avec pg_dump mais c'est sur la façon de les sauvegarder que je souhaiterai avoir l'avis d'utilisateurs expérimentés.

Les bases sont sur un seul serveur dans un sous-réseau 192.168
Deux utilisateurs peuvent les utiliser en lecture/écriture
Ces deux utilisateurs ont des bases en commun par contre, certaines de leur bases leur sont privées.
Il n'y a pas de gros objets binaires.
Je saurai définir la fréquence des sauvegardes plus tard.
Les sauvegardes vont être mises temporairement sur le même serveur puis elles seront dupliquées (scp) - ou déplacées (je ne sais pas encore) - sur une autre machine.
Je n'ai pas encore l'expérience de précautions des sauvegardes au cours de transactions/rollback.

1)
Pour les sauvegardes ce que j'aimerai savoir c'est si il est préférable :
- que ce soit chaque user unix qui sauvegarde ses propres bases par une crontab. Quid des bases communes?
- ou que je créé un utilisateur unix qui serait uniquement chargé de toutes les sauvegardes mises dans une crontab en préservant les droits de chacun dans le(s) script(s)?

2)
Vu mon expérience de novice, je ne sais pas s'il est préférable de sauvegarder les données d'une part et les structures d'une autre part ou au contraire de tout mettre dans le même dump.
J'ai compris que sauvegarder l'ensemble d'une base avec plusieurs tables/view/sequences/etc... est moins pratique pour restorer ponctuellement.

3)
J'ai aussi vu la possibilité de sauvegarder directement les fichiers des bases mais, pour des très petits volumes, je ne vois pas l'avantage par rapport à pg_dump.

Merci d'avance pour toutes vos suggestions sur les sauvegardes vues sous l'angle de la sécurité.

Alain V. · Général

Oui, c'est plus clair maintenant.

Alain V. · Général

Je n'avais pas compris qu'une séquence n'était prise en compte que sur un INSERT sans valeur pour la colonne t_00_noid (ou avec la valeur DEFAULT).

Je pensais aussi que la clef primaire que j'avais mise dessus permettait de préserver les valeurs détruites de toute réutilisation future :
ALTER TABLE ONLY t_00_dic_medical
ADD CONSTRAINT t_00_dic_medical_pkey PRIMARY KEY (t_00_noid);

Il faut donc que je revoie la contrainte sur la colonne.

Encore merci pour le coup de pouce.

Alain V. · Général

Merci pour votre intérêt.

Voici ce que j'ai fait avec le dump qui génère le message d'erreur :

bd_archimede=> SELECT * FROM t_00_dic_medical;
 t_00_noid | t_00_tri |   t_00_jp    | t_00_class |       t_00_fr        | t_00_fr_gramm | t_00_uk | t_00_uk_gramm |                          t_00_explication
-----------+----------+--------------+------------+----------------------+---------------+---------+---------------+--------------------------------------------------------------------
         1 |        2 | いぼ（疣）   |            | verrue               | nf            |         |               |
         2 |       11 | 傷を焼灼する |            | cautériser une plaie |               |         |               | en brûler superficiellement les tissus afin d'éviter son infection
         7 |        0 |              |            | français             |               |         |               |
(3 lignes)

bd_archimede=> TRUNCATE t_00_dic_medical ;
TRUNCATE TABLE
bd_archimede=>

En ligne de commande :

$ psql -h 192.168.3.105 -U archimede -W bd_archimede < dump_t_00_dic_medical.txt
Mot de passe pour l'utilisateur archimede :
SET
SET
SET
SET
SET
SET
SET
SET
ERREUR:  la relation « t_00_dic_medical » existe déjà
ALTER TABLE
COMMENT
COMMENT
COMMENT
COMMENT
COMMENT
COMMENT
COMMENT
COMMENT
COMMENT
ERREUR:  la relation « t_00_dic_medical_t_00_noid_seq » existe déjà
ALTER TABLE
ALTER SEQUENCE
 setval
--------
      6
(1 ligne)

ALTER TABLE
INSERT 0 1
INSERT 0 1
ERREUR:  les clés primaires multiples ne sont pas autorisées pour la table « t_00_dic_medical »
ATTENTION:  aucun droit n'a pu être révoqué pour « public »
REVOKE
ATTENTION:  aucun droit n'a pu être révoqué pour « public »
REVOKE
ATTENTION:  aucun droit n'a été accordé pour « public »
GRANT
ATTENTION:  aucun droit n'a été accordé pour « public »
GRANT
$

Le dump :

--
-- PostgreSQL database dump
--

SET client_encoding = 'UTF8';
SET standard_conforming_strings = off;
SET check_function_bodies = false;
SET client_min_messages = warning;
SET escape_string_warning = off;

SET search_path = public, pg_catalog;

SET default_tablespace = '';

SET default_with_oids = false;

--
-- Name: t_00_dic_medical; Type: TABLE; Schema: public; Owner: archimede; Tablespace: 
--

CREATE TABLE t_00_dic_medical (
    t_00_noid bigint NOT NULL,
    t_00_tri numeric(6,0) DEFAULT 0,
    t_00_jp character varying(100),
    t_00_class character varying(10),
    t_00_fr character varying(100),
    t_00_fr_gramm character varying(10),
    t_00_uk character varying(100),
    t_00_uk_gramm character varying(10),
    t_00_explication text
);


ALTER TABLE public.t_00_dic_medical OWNER TO archimede;

--
-- Name: COLUMN t_00_dic_medical.t_00_noid; Type: COMMENT; Schema: public; Owner: archimede
--

COMMENT ON COLUMN t_00_dic_medical.t_00_noid IS 'Numérotation auto-incrémentée. Maximum = ???? Avec clef primaire';


--
-- Name: COLUMN t_00_dic_medical.t_00_tri; Type: COMMENT; Schema: public; Owner: archimede
--

COMMENT ON COLUMN t_00_dic_medical.t_00_tri IS 'Numéro de tri. Maximum = 1.000.000 de lignes dans ce dictionnaire';


--
-- Name: COLUMN t_00_dic_medical.t_00_jp; Type: COMMENT; Schema: public; Owner: archimede
--

COMMENT ON COLUMN t_00_dic_medical.t_00_jp IS 'Japonais. Limite 100 caractères. A voir les doubles octets';


--
-- Name: COLUMN t_00_dic_medical.t_00_class; Type: COMMENT; Schema: public; Owner: archimede
--

COMMENT ON COLUMN t_00_dic_medical.t_00_class IS 'Japonais pour classement. Limite 10 caractères. A voir les doubles octets';


--
-- Name: COLUMN t_00_dic_medical.t_00_fr; Type: COMMENT; Schema: public; Owner: archimede
--

COMMENT ON COLUMN t_00_dic_medical.t_00_fr IS 'Français. Limite 100 caractères.';


--
-- Name: COLUMN t_00_dic_medical.t_00_fr_gramm; Type: COMMENT; Schema: public; Owner: archimede
--

COMMENT ON COLUMN t_00_dic_medical.t_00_fr_gramm IS 'Français. Grammaire. Limite 10 caractères.';


--
-- Name: COLUMN t_00_dic_medical.t_00_uk; Type: COMMENT; Schema: public; Owner: archimede
--

COMMENT ON COLUMN t_00_dic_medical.t_00_uk IS 'Anglais. Limite 100 caractères.';


--
-- Name: COLUMN t_00_dic_medical.t_00_uk_gramm; Type: COMMENT; Schema: public; Owner: archimede
--

COMMENT ON COLUMN t_00_dic_medical.t_00_uk_gramm IS 'Anglais. Grammaire. Limite 10 caractères.';


--
-- Name: COLUMN t_00_dic_medical.t_00_explication; Type: COMMENT; Schema: public; Owner: archimede
--

COMMENT ON COLUMN t_00_dic_medical.t_00_explication IS 'Explication. Type de champs texte';


--
-- Name: t_00_dic_medical_t_00_noid_seq; Type: SEQUENCE; Schema: public; Owner: archimede
--

CREATE SEQUENCE t_00_dic_medical_t_00_noid_seq
    INCREMENT BY 1
    NO MAXVALUE
    NO MINVALUE
    CACHE 1;


ALTER TABLE public.t_00_dic_medical_t_00_noid_seq OWNER TO archimede;

--
-- Name: t_00_dic_medical_t_00_noid_seq; Type: SEQUENCE OWNED BY; Schema: public; Owner: archimede
--

ALTER SEQUENCE t_00_dic_medical_t_00_noid_seq OWNED BY t_00_dic_medical.t_00_noid;


--
-- Name: t_00_dic_medical_t_00_noid_seq; Type: SEQUENCE SET; Schema: public; Owner: archimede
--

SELECT pg_catalog.setval('t_00_dic_medical_t_00_noid_seq', 6, true);


--
-- Name: t_00_noid; Type: DEFAULT; Schema: public; Owner: archimede
--

ALTER TABLE t_00_dic_medical ALTER COLUMN t_00_noid SET DEFAULT nextval('t_00_dic_medical_t_00_noid_seq'::regclass);


--
-- Data for Name: t_00_dic_medical; Type: TABLE DATA; Schema: public; Owner: archimede
--

INSERT INTO t_00_dic_medical (t_00_noid, t_00_tri, t_00_jp, t_00_class, t_00_fr, t_00_fr_gramm, t_00_uk, t_00_uk_gramm, t_00_explication) VALUES (1, 2, 'いぼ（疣）', '', 'verrue', 'nf', '', '', NULL);
INSERT INTO t_00_dic_medical (t_00_noid, t_00_tri, t_00_jp, t_00_class, t_00_fr, t_00_fr_gramm, t_00_uk, t_00_uk_gramm, t_00_explication) VALUES (2, 11, '傷を焼灼する', '', 'cautériser une plaie', '', NULL, '', 'en brûler superficiellement les tissus afin d''éviter son infection');


--
-- Name: t_00_dic_medical_pkey; Type: CONSTRAINT; Schema: public; Owner: archimede; Tablespace: 
--

ALTER TABLE ONLY t_00_dic_medical
    ADD CONSTRAINT t_00_dic_medical_pkey PRIMARY KEY (t_00_noid);


--
-- Name: public; Type: ACL; Schema: -; Owner: postgres
--

REVOKE ALL ON SCHEMA public FROM PUBLIC;
REVOKE ALL ON SCHEMA public FROM postgres;
GRANT ALL ON SCHEMA public TO postgres;
GRANT ALL ON SCHEMA public TO PUBLIC;


--
-- PostgreSQL database dump complete
--

Et le nouveau remplissage de la table :

bd_archimede=> SELECT * FROM t_00_dic_medical;
 t_00_noid | t_00_tri |   t_00_jp    | t_00_class |       t_00_fr        | t_00_fr_gramm | t_00_uk | t_00_uk_gramm |                          t_00_explication
-----------+----------+--------------+------------+----------------------+---------------+---------+---------------+--------------------------------------------------------------------
         1 |        2 | いぼ（疣）   |            | verrue               | nf            |         |               |
         2 |       11 | 傷を焼灼する |            | cautériser une plaie |               |         |               | en brûler superficiellement les tissus afin d'éviter son infection
(2 lignes)

bd_archimede=>

Je n'ai passé aucune autre commande, ni côté serveur, ni sur ma machine. Vous avez ici dans l'ordre la totalité de ce que je vois et de ce que j'ai exécuté.

Alain V. · Général

satya a écrit :

je voudrais transférer des tables précise

Cela devrait aller avec :
$ pg_dump -D -h ipdistante -U user -W labonnebase -t labonnetable > fichierdesauvegarde

Alain V. · Général

Bonjour le forum.

Suite à un TRUNCATE TABLE qui ne détruit pas le compteur je m'attendais à ce que la progression de la séquence continue en tenant compte de la valeur "last_value" du catalogue.
Lors du repeuplement de cette table devenue vide j'ai constaté que la valeur "last_value" était bien prise en compte mais qu'il était quand même possible de réutiliser des valeurs détruites.

Est-ce normal qu'un INSERT INTO des valeurs de séquences ayant été déjà utilisées soient acceptées quand même avec le message d'erreur "clés primaires multiples ne sont pas autorisées"?

Voici un extrait de la table. Pour la lisibilité, j'ai supprimé les ALTER TABLE... OWNER TO.

CREATE TABLE t_00_dic_medical (
    t_00_noid bigint NOT NULL,
    t_00_tri numeric(6,0) DEFAULT 0,
    t_00_jp character varying(100),
    [...]

La totalité de la séquence avec une valeur 6 pour "last_value" :

CREATE SEQUENCE t_00_dic_medical_t_00_noid_seq
    INCREMENT BY 1
    NO MAXVALUE
    NO MINVALUE
    CACHE 1;
ALTER SEQUENCE t_00_dic_medical_t_00_noid_seq OWNED BY t_00_dic_medical.t_00_noid;
SELECT pg_catalog.setval('t_00_dic_medical_t_00_noid_seq', 6, true);
ALTER TABLE t_00_dic_medical ALTER COLUMN t_00_noid SET DEFAULT nextval('t_00_dic_medical_t_00_noid_seq'::regclass);

Je peuple un peu la table pour tester. Le compteur monte à 6. Je la "truncate" puis je la repeuple à nouveau avec ce dump :

INSERT INTO t_00_dic_medical (t_00_noid, t_00_tri, t_00_jp, [...]) VALUES (1, 2, 'いぼ（疣）', [...]); (notez la valeur 1 entrée en première colonne)
INSERT INTO t_00_dic_medical (t_00_noid, t_00_tri, t_00_jp, [...]) VALUES (2, 11, '傷を焼灼する',[...]); (notez la valeur 2 entrée en première colonne)
ALTER TABLE ONLY t_00_dic_medical
    ADD CONSTRAINT t_00_dic_medical_pkey PRIMARY KEY (t_00_noid);

L'erreur :

$psql labonnebase < dump.txt
[...]
ERREUR:  la relation « t_00_dic_medical » existe déjà (Ce message me semble normal car la description de la table est aussi dans le dump)
ALTER TABLE
ERREUR:  la relation « t_00_dic_medical_t_00_noid_seq » existe déjà (Ce message me semble normal puisque je n'ai fait que "truncaté" la table et non "droppée")
ALTER TABLE
ALTER SEQUENCE
 setval
--------
      6
(1 ligne)

ALTER TABLE
INSERT 0 1
INSERT 0 1
ERREUR:  les clés primaires multiples ne sont pas autorisées pour la table « t_00_dic_medical »

Le résultat :

 t_00_noid | t_00_tri |   t_00_jp    |
-----------+----------+--------------+
         1 |        2 | いぼ（疣）   |
         2 |       11 | 傷を焼灼する |
         7 |        0 |              |

Pour la première colonne, je m'attendais à ce qu'on m'interdise le INSERT INTO 1, 2 et que la séquence reprenne à partir de 7. Je m'attendais donc à cette seule séquence autorisée : 7, 8, 9, et non 1, 2, 7 que j'ai forcé.

La valeur de la séquence dans le catalogue :

select * from t_00_dic_medical_t_00_noid_seq ;
         sequence_name          | last_value | increment_by |      max_value      | min_value | cache_value | log_cnt | is_cycled | is_called
--------------------------------+------------+--------------+---------------------+-----------+-------------+---------+-----------+-----------
 t_00_dic_medical_t_00_noid_seq |          7 |            1 | 9223372036854775807 |         1 |           1 |      32 | f         | t

Où est-ce que j'ai fait une erreur?
Qu'est-ce que je n'ai pas compris?

Merci beaucoup d'avance pour le temps que vous accorderez à mes interrogations.

Alain V. · Général

gleu a écrit :

Alain V. a écrit :
create database role legroupe role leuser1, leuser2;
Je ne sais pas du tout ce que vous entendez par là.

Effectivement je suis en train de mélanger la notion de groupe avec celle d'une database!

Merci pour le lien. Je vais m'y accrocher.

Alain V. · Général

Fab du 07 a écrit :

je dois insérer des informations avec des accents, ce qui n'est pas supporté par ce type d'encodage..

Bonjour,

Moi je peux utiliser tous les accents avec UTF-8.
Je peux aussi utiliser indistinctement les caractères des langues asiatiques.

D'ailleurs, je n'utilise plus que UTF-8, car qui peut le plus, peut le moins.

Alain V. · Général

Bonjour le forum,

Je ne sais pas trop comment formuler mes recherches dans la documentation.

Ce que je veux faire :
- une database de plusieurs tables accessibles à au moins trois users.
- l'un deux ne pourrait que lire (select?) les tables et les vues
- l'autre pourrait altérer (insérer/droper/updater/truncater?) toutes les colonnes, les tuples et bien sûr les tables.
- un troisième ne pourrait qu'insérer et updater quelques colonnes seulement sans possibilité de détruire des données (ajouts + modifs autorisés mais pas de suppressions).
Ce que j'ai fait :
Sous l'utilisateur postgres j'ai commencé par créer un groupe en croyant que ce groupe ne devrait pas avoir de login (aucune entrée dans /etc/password) et en commençant pas deux users :
create database role legroupe role leuser1, leuser2;

Ensuite je patauge allègrement pour attribuer une database à ce groupe sous un autre proprio que postgres tout en grantant des droits différents à chacun des users sur les tables.
J'ai compris que les privilèges accordés aux users sont distincts que ceux du groupe auquel ils appartiennent.
J'ai tenté de tester dans tous les sens (jusqu'à le vider) le pg_hba.conf avec la désagréable sensation que ce ne doit pas être la bonne voie car les accès ne semblent pas être affectés.
Sinon, hormis cette tentative d'avoir un groupe, le pg_hba.conf semble bien correspondre à ce que j'en attends.

Dans cette doc http://docs.postgresqlfr.org/8.2/sql-grant.html je n'ai compris que la possiblité de granter un user sur une table et non plusieurs users sur plusieurs tables au sein d'une seule database.

Je suis désolé si ma description est tordue, mal ou incomplètement formulée.
Est-ce que quelqu'un aurait un lien vers un tuto qui parle de groupes / d'utilisateurs avec des exemples montrant des droits différents sur les tables?

Merci beaucoup par avance de me mettre sur des voies de recherche ou de m'expliquer ce que je n'ai pas compris dans la doc.

Alain V. · Général

Merci beaucoup. Cela me permet d'orienter mes recherches différemment.

Alain V. · Général

D'après ce que j'ai compris pgloader prend en entrée un fichier plat.
J'ai effectivement ce fichier plat mais je souhaite m'en débarasser.
Ce que je cherche à faire c'est que les recettes de Procmail aillent déverser directement dans une table Postgres pour ne plus passer par ce fichier plat.
Il y a un flux constant qui l'alimente. Actuellement je suis obligé d'arrêter le flux manuellement, vider ce fichier et remettre le flux.
Je crains de perdre des données avec pgloader si une telle manip doit être automatisée.

Ce que je cherche, c'est le maillon final pour cette chaine :
Fetchmail ---> Procmail ---> Postgres
au lieu de :
Fetchmail ---> Procmail ---> fichier plat--->Phppgadmin--->Postgres

Est-ce envisageable avec pgloader sans interruption de flux ?
Fetchmail ---> Procmail ---> fichier plat--->pgloader--->Postgres

Alain V. · Général

Merci beaucoup. Je vais regarder ça.

#1 Re : Général » [Résol]Calculer le nombre de km parcourus entre deux relevés compteurs » 04/08/2016 17:08:33

#2 Re : Général » [Résol]Calculer le nombre de km parcourus entre deux relevés compteurs » 04/08/2016 14:28:45

#3 Re : Général » [Résol]Calculer le nombre de km parcourus entre deux relevés compteurs » 04/08/2016 12:51:22

#4 Général » [Résol]Calculer le nombre de km parcourus entre deux relevés compteurs » 04/08/2016 11:53:22

#5 Re : Général » [Résolu] Formatage de données TIME » 27/06/2016 16:35:37

#6 Général » [Résolu] Formatage de données TIME » 27/06/2016 15:38:15

#7 Re : Général » La colonne « reltriggers » n'existe pas » 04/02/2011 10:12:45

#8 Re : Général » La colonne « reltriggers » n'existe pas » 03/02/2011 20:22:23

#9 Général » La colonne « reltriggers » n'existe pas » 03/02/2011 17:25:38

#10 Re : Général » [débutant] Séquence ou identifiant? » 09/09/2010 21:40:27

#11 Re : Général » [débutant] Séquence ou identifiant? » 09/09/2010 20:08:57

#12 Général » [débutant] Séquence ou identifiant? » 09/09/2010 18:52:48

#13 Re : Sécurité » [Débutant] Méthode des sauvegardes vue sous l'angle de la sécurité. » 15/07/2010 12:41:01

#14 Sécurité » [Débutant] Méthode des sauvegardes vue sous l'angle de la sécurité. » 13/07/2010 19:23:19

#15 Re : Général » [Débutant] Réutilisation de numéros de séquence » 10/06/2010 16:28:14

#16 Re : Général » [Débutant] Réutilisation de numéros de séquence » 10/06/2010 16:14:18

#17 Re : Général » [Débutant] Réutilisation de numéros de séquence » 10/06/2010 15:47:22

#18 Re : Général » transfert de table dans une autre base de donnée » 10/06/2010 13:10:07

#19 Général » [Débutant] Réutilisation de numéros de séquence » 10/06/2010 13:00:16

#20 Re : Général » [Débutant] Comment organiser un groupe? » 27/05/2010 10:18:08

#21 Re : Général » Changement d'encodage » 27/05/2010 09:33:51

#22 Général » [Débutant] Comment organiser un groupe? » 27/05/2010 04:27:36

#23 Re : Général » Remplissage de table depuis Procmail » 21/05/2010 14:21:11

#24 Re : Général » Remplissage de table depuis Procmail » 21/05/2010 13:54:27

#25 Re : Général » Remplissage de table depuis Procmail » 21/05/2010 10:21:26

Pied de page des forums

PostgreSQL.fr

À propos

Nous contacter

Groupes Locaux

Réseaux Sociaux