Vous n'êtes pas identifié(e).
Pages : 1
Bonjour,
Alors ca doit être moi, j'ai du raté ou une subtilité très fine ou un truc énorme, mais sous windows, j'ai des soucis avec pg_dump....
Alors mise dans le contexte :
Windows XP
postgreSQL 8.4 (la 8.4.11.1 pour être précis)
j'ai configuré la variable d'environnement PATH pour que les exécutables soient vus proprement
j'ai une base de données BDD1
BDD1 contient le schéma public
ce schéma public contient plusieurs tables dont Ana_Date (date des analyses)
pour dumper la structure d'une base de donnée je tape:
PS Y:\> pg_dump -h 127.0.0.1 -p 5432 -U postgres -v -F p -d -s -t public.* BDD1Bien j'obtiens des trucs sympas, mais sur TOUT (toutes les tables, séquences, etc... )
Or, comme je veux restreindre cela uniquement à ma table Ana_Date, je tape naïvement
PS Y:\> pg_dump -h 127.0.0.1 -p 5432 -U postgres -v -F p -d -s -t public."Ana_Date" BDD1
PS Y:\> pg_dump -h 127.0.0.1 -p 5432 -U postgres -v -F p -d -s -t public.Ana_Date BDD1
PS Y:\> pg_dump -h 127.0.0.1 -p 5432 -U postgres -v -F p -d -s -t *."Ana_Date" BDD1
PS Y:\> pg_dump -h 127.0.0.1 -p 5432 -U postgres -v -F p -d -s -t *.Ana_Date BDD1(j'ai testé les différents pattern, avec/sans guillemets)
et là, c'est le drame à chaque fois:
pg_dump: Aucune table correspondante n'a été trouvée
pg_dump: *** interrompu du fait d'erreurspour info, la commande copy de psql fonctionne très bien
BDD1=# \copy "Ana_Date" to y:\SQL\toto.dmpEst-ce que tout simplement filtrer des tables est impossible sous windows...?
Est-ce qu'au bout de la 4ème lecture de la manpage de pg_dump, il y a encore quelque chose que j'ai raté ?
Post Scriptum:
Avec pgAdmin, je peux évidemment récupérer la structure de la table qui m'intéresse, mais la finalité de tout cela, c'est qd même récupérer uniquement les données : option "-a" au lieu de l'option "-s"
Dernière modification par zephura (05/03/2012 20:31:43)
Hors ligne
Bonjour.
Avez-vous essayé avec un pattern -t \"Ana_Date\" ou -t '"Ana_Date"'?
Julien.
https://rjuju.github.io/
Hors ligne
oui, j'ai essayé ca aussi...
"\"Ana_Date\"" > fourni une erreur regexp, problème d'équilibrage des parenthèses !!!
'"Ana_date"' > rien
Ana_Date > même message d'erreur
\"Ana_Date\" > plus subtile, pg_dump considère qu'il s'agit du nom de la BdD et m'indique donc que le 1er argument (donc le nom de la base de données) est BDD1
Hors ligne
Est-ce que la syntaxe suivante fonctionne ?
-n public -t "Ana_Date"
Julien.
https://rjuju.github.io/
Hors ligne
J'avais vu dans la manpage de pg_dump que l'option -n était zappé lorsque l'option -t était présente, mais j'ai essayé aussi et meme résultat
Attention, l'option "-n public" SEULE fonctionne, mais encore une fois elle me sort toute la base....
Hors ligne
Alors je viens de faire un test stupide, mais qui pourrait donné des pistes...
PS Y:\> pg_dump -h 127.0.0.1 -p 5432 -U postgres -v -F p --inserts -s -t pg_am BDD1
PS Y:\> pg_dump -h 127.0.0.1 -p 5432 -U postgres -v -F p --inserts -a -t pg_am BDD1Me sort quelque-chose d'intéressant sur la table pg_am.
Donc de ce que j'en crois, pg_dump sait parcourir les catalogues
Dernière modification par zephura (06/03/2012 11:38:02)
Hors ligne
Je viens de tester sur un environnement windows, le -n n'est effectivement pas utile. Il faut utiliser la syntaxe suivante :
-t public.\"Ana_Date\"
et cela fonctionne.
Julien.
https://rjuju.github.io/
Hors ligne
Autre test débile, mais qui m'aiguille très fortement cette fois...
je viens de créer une table "test" (notez la casse, tout en minuscule)
PS Y:\> pg_dump -h 127.0.0.1 -p 5432 -U postgres -v -F p --inserts -s -t test BDD1bon je passe sur le blabla lié au [i]verbose[i/] voici le résultat
-- TOC entry 162 (class 1259 OID 17661)
-- Dependencies: 6
-- Name: test; Type: TABLE; Schema: public; Owner: postgres; Tablespace:
--
CREATE TABLE test (
toto text NOT NULL
);
ALTER TABLE public.test OWNER TO postgres;
pg_dump: création de CONSTRAINT test_pkey
--
-- TOC entry 1847 (class 2606 OID 17668)
-- Dependencies: 162 162
-- Name: test_pkey; Type: CONSTRAINT; Schema: public; Owner: postgres; Tablespace:
--
ALTER TABLE ONLY test
ADD CONSTRAINT test_pkey PRIMARY KEY (toto);Donc a priori, mon problème viendrait dans la casse de ma table "Ana_Date"...
solution 1 : trouver comment appeler proprement cette table depuis pg_dump
solution 2 : modifier la casse de toutes mes tables en ne mettant QUE des minuscules (et donc changer le code php qui est déjà utilisé...)
solution 3 : réussir a faire un lien entre mes tables et des tables virtuelles
Hors ligne
Si vous utilisez "-n public" seule, elle ne doit vous fournir que les objets compris dans le schéma public. Si vous n'utilisez que ce schéma, il est logique que vous vous retrouviez avec toute la base. L'option -n n'est pas ignorée si vous utilisez l'option -t, c'est au contraire ce qui vous permet d'indiquer un autre schéma.
Pour répondre à votre problème initial, sous Unix, il a fallu que je fasse ceci :
pg_dump -t '"Ana_Date"' BDD1guillemet simple, suivi d'un guillemet double, suivi du nom de la table, suivi d'un guillemet double, suivi d'un guillement simple.
Pas sûr que ce soit la même chose sous Windows mais je n'ai pas de Windows sous la main actuellement.
Guillaume.
Hors ligne
Je viens de voir que j'ai écris une bêtise concernant l'utilisation simultanée des options -n et -t. Si -t est indiqué, le -n est ignoré. Toutes mes excuses.
Du coup, si la table se trouve dans un autre schéma que la liste des schémas pas défaut, il faut faire ceci :
pg_dump -t 'schema."Ana_Date"' BDD1Guillaume.
Hors ligne
Alors voici le test avec \":
PS Y:\SQL> pg_dump -h 127.0.0.1 -p 5432 -U postgres --inserts -F p -s -t public."\Ana_Date\" BDD1
Mot de passe :
pg_dump: la commande SQL a échoué
pg_dump: Message d'erreur du serveur : ERREUR: expression rationnelle invalide : parentheses () not balanced
pg_dump: La commande était : SELECT c.oid
FROM pg_catalog.pg_class c
LEFT JOIN pg_catalog.pg_namespace n ON n.oid = c.relnamespace
WHERE c.relkind in ('r', 'S', 'v')
AND c.relname ~ E'^(\\ana_date\\)$'
AND n.nspname ~ '^(public)$'par contre en continuant sur l'idée de la casse, voici le test que j'ai fait en remplace les majuscules par des "?":
PS Y:\SQL> pg_dump -h 127.0.0.1 -p 5432 -U postgres --inserts -F p -s -t public.?na_?ate Clients
Mot de passe :
--
-- PostgreSQL database dump
--
SET statement_timeout = 0;
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;
-- // snip //
CREATE TABLE "Ana_Date" (
"Id_Date" bigint DEFAULT nextval('"Ana_Date_seq"'::regclass) NOT NULL,
"Date" timestamp without time zone
);
ALTER TABLE public."Ana_Date" OWNER TO postgres;
-- // snip //
ALTER TABLE ONLY "Ana_Date"
ADD CONSTRAINT "Ana_Date_pkey" PRIMARY KEY ("Id_Date");
--
-- PostgreSQL database dump complete
--Ce n'est pas très élégant, mais dans un premier temps, ca fonctionne.
Par contre j'ai une table qui elle a un nom avec uniquement des majuscules, et là, pas moyen... donc je dois continuer à chercher ou passer à la solution 2.... :s
Hors ligne
gleu>
même résultat...
PS Y:\SQL> pg_dump -h 127.0.0.1 -p 5432 -U postgres --inserts -F p -s -t 'public."Ana_Date"' BDD1
Mot de passe :
pg_dump: Aucune table correspondante n'a été trouvéemême résultat avec 'public.Ana_Date'
Hors ligne
CA Y EST, je l'ai
merci à gleu et rjuju de s'être penché sur mon problème, et avec vos conseils, j'ai fait un test qui a fonctionné
-t 'public.\"Ana_Date\"'
PS Y:\SQL> pg_dump -h 127.0.0.1 -p 5432 -U postgres --inserts -F p -s -t 'public.\"Ana_Date\"' BDD1
Mot de passe :
--
-- PostgreSQL database dump
--
SET statement_timeout = 0;
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;
-- // snip//
CREATE TABLE "Ana_Date" (
"Id_Date" bigint DEFAULT nextval('"Ana_Date_seq"'::regclass) NOT NULL,
"Date" timestamp without time zone
);
-- // snip//
ALTER TABLE ONLY "Ana_Date"
ADD CONSTRAINT "Ana_Date_pkey" PRIMARY KEY ("Id_Date");
--
-- PostgreSQL database dump complete
--Bien évidemment, à moi de faire attention lors de l'utilisation de cette sauvegarde si je veux l'utiliser dans pg_restore, car la séquence "Ana_Date_seq" par exemple n'est pas exportée ici
Dernière modification par zephura (06/03/2012 12:33:26)
Hors ligne
Pages : 1