Thread: set search_path and pg_dumpall

set search_path and pg_dumpall

From
ohp@pyrenet.fr
Date:
Hi all,

Still trying to upgrade from 7.3.4 to 7.4.1 with pg_dumpall.
2 problemes:

When a serch_path has been set, pg_dumpall correctly output a alter
database xxx set search_path to 'xxx' but *BEFORE* the schema is created
so it doesn't work.

And about my previous mails, if I pg_dump the database I have problems
with, it reloads without problems but it I pg_dumpall then I have the
problems I wrote before.

Here part of the log file:

ERROR:  extra data after last expected column
ERROR:  missing data for column "msg_date2"
ERROR:  missing data for column "guilde_valide"
ERROR:  insert or update on table "guilde_rang" violates foreign key constraint "$1"
ERROR:  insert or update on table "guilde_perso" violates foreign key constraint "$1"

here are the table schema:

--
-- PostgreSQL database dump
--

SET SESSION AUTHORIZATION 'sdewitte';

SET search_path = public, pg_catalog;

--
-- TOC entry 2 (OID 31845735)
-- Name: messages; Type: TABLE; Schema: public; Owner: sdewitte
--

CREATE TABLE messages (   msg_cod integer DEFAULT nextval('seq_msg_cod'::text) NOT NULL,   msg_date date NOT NULL,
msg_titrecharacter varying(50),   msg_corps text,   msg_date2 timestamp with time zone
 
);


--
-- TOC entry 4 (OID 37161058)
-- Name: messages_msg_cod_key; Type: INDEX; Schema: public; Owner: sdewitte
--

CREATE INDEX messages_msg_cod_key ON messages USING btree (msg_cod);


--
-- TOC entry 5 (OID 37161059)
-- Name: messages_msg_date_key; Type: INDEX; Schema: public; Owner: sdewitte
--

CREATE INDEX messages_msg_date_key ON messages USING btree (msg_date);


--
-- TOC entry 7 (OID 37161115)
-- Name: msg_date2_messages_key; Type: INDEX; Schema: public; Owner: sdewitte
--

CREATE INDEX msg_date2_messages_key ON messages USING btree (msg_date2);


--
-- TOC entry 6 (OID 37161292)
-- Name: messages_pkey; Type: CONSTRAINT; Schema: public; Owner: sdewitte
--

ALTER TABLE ONLY messages   ADD CONSTRAINT messages_pkey PRIMARY KEY (msg_cod);


--
-- TOC entry 8 (OID 37161665)
-- Name: RI_ConstraintTrigger_37161665; Type: TRIGGER; Schema: public; Owner: sdewitte
--

CREATE CONSTRAINT TRIGGER "<unnamed>"   AFTER DELETE ON messages   FROM messages_dest   NOT DEFERRABLE INITIALLY
IMMEDIATE  FOR EACH ROW   EXECUTE PROCEDURE "RI_FKey_noaction_del"('<unnamed>', 'messages_dest', 'messages',
'UNSPECIFIED','dmsg_msg_cod', 'msg_cod');
 


--
-- TOC entry 9 (OID 37161666)
-- Name: RI_ConstraintTrigger_37161666; Type: TRIGGER; Schema: public; Owner: sdewitte
--

CREATE CONSTRAINT TRIGGER "<unnamed>"   AFTER UPDATE ON messages   FROM messages_dest   NOT DEFERRABLE INITIALLY
IMMEDIATE  FOR EACH ROW   EXECUTE PROCEDURE "RI_FKey_noaction_upd"('<unnamed>', 'messages_dest', 'messages',
'UNSPECIFIED','dmsg_msg_cod', 'msg_cod');
 


--
-- TOC entry 10 (OID 37161671)
-- Name: RI_ConstraintTrigger_37161671; Type: TRIGGER; Schema: public; Owner: sdewitte
--

CREATE CONSTRAINT TRIGGER "<unnamed>"   AFTER DELETE ON messages   FROM messages_exp   NOT DEFERRABLE INITIALLY
IMMEDIATE  FOR EACH ROW   EXECUTE PROCEDURE "RI_FKey_noaction_del"('<unnamed>', 'messages_exp', 'messages',
'UNSPECIFIED','emsg_msg_cod', 'msg_cod');
 


--
-- TOC entry 11 (OID 37161672)
-- Name: RI_ConstraintTrigger_37161672; Type: TRIGGER; Schema: public; Owner: sdewitte
--

CREATE CONSTRAINT TRIGGER "<unnamed>"   AFTER UPDATE ON messages   FROM messages_exp   NOT DEFERRABLE INITIALLY
IMMEDIATE  FOR EACH ROW   EXECUTE PROCEDURE "RI_FKey_noaction_upd"('<unnamed>', 'messages_exp', 'messages',
'UNSPECIFIED','emsg_msg_cod', 'msg_cod');
 


--
-- TOC entry 3 (OID 31845735)
-- Name: TABLE messages; Type: COMMENT; Schema: public; Owner: sdewitte
--

COMMENT ON TABLE messages IS 'Messages internes';


--
-- PostgreSQL database dump
--

SET SESSION AUTHORIZATION 'sdewitte';

SET search_path = public, pg_catalog;

--
-- TOC entry 2 (OID 31845953)
-- Name: guilde; Type: TABLE; Schema: public; Owner: sdewitte
--

CREATE TABLE guilde (   guilde_cod integer DEFAULT nextval('seq_guilde_cod'::text) NOT NULL,   guilde_nom character
varying(100)NOT NULL,   guilde_description text NOT NULL,   guilde_valide character varying(2) DEFAULT 'O'::character
varyingNOT NULL
 
);


--
-- TOC entry 4 (OID 37161158)
-- Name: guilde_guilde_cod_key; Type: INDEX; Schema: public; Owner: sdewitte
--

CREATE INDEX guilde_guilde_cod_key ON guilde USING btree (guilde_cod);


--
-- TOC entry 6 (OID 37161265)
-- Name: guilde_valide_guilde_key; Type: INDEX; Schema: public; Owner: sdewitte
--

CREATE INDEX guilde_valide_guilde_key ON guilde USING btree (guilde_valide);


--
-- TOC entry 5 (OID 37161364)
-- Name: guilde_pkey; Type: CONSTRAINT; Schema: public; Owner: sdewitte
--

ALTER TABLE ONLY guilde   ADD CONSTRAINT guilde_pkey PRIMARY KEY (guilde_cod);


--
-- TOC entry 3 (OID 31845953)
-- Name: TABLE guilde; Type: COMMENT; Schema: public; Owner: sdewitte
--

COMMENT ON TABLE guilde IS 'Liste des guildes';


and the offending lines:
guilde:
18    Septième Compagnie    En Mémoire de ceux qui, durant des heures sombres, ont inventé la fameuse et infaillible
tactiquede la "tenaille"...<br />\r\nLeur esprit n'est pas mort...<br />\r\nA notre tour d'utiliser cette ingénieuse
stratégie...<br/>\r\n<hr WIDTH="100%"><b>LES FONDATEURS:</b><TABLE cellspacing=4 cellpadding=0 border=0><TR><TD
align="center"><IMGsrc="http://fandersson.free.fr/delain/images/alien2.jpg" border="2"> </TD><TD align="left"><font
size=-1><b><u>LEBON:</u></b> ALIEN2, le tourbillon mental. Il voit au-delà de ce qui peut être vu... </font></TD><TD
align="center"><IMGsrc="http://fandersson.free.fr/delain/images/gerard.jpg" border="2"> </TD><TD align="left"><font
size=-1><b><u>LABRUTE:</u></b> Le colonel GERARD. "Le fil vert, sur le bouton vert, le fil rouge, sur le bouton
rouge..."</font></TD><TDalign="center"><IMG src="http://fandersson.free.fr/delain/images/laerte.jpg" border="2">
</TD><TDalign="left"><font size=-1><b><u>LE TRUAND:</u></b> LAERTE, L'homme aux mille noms. Rapide comme l'éclair,
puissantcomme le tonnerre, fulgurant comme la foudre.</font></TD></TR></TABLE><hr WIDTH="100%"><TABLE cellspacing=4
cellpadding=0border=0><TR><TD align="center"><IMG src="http://fandersson.free.fr/delain/images/vodka.gif" border="2">
</TD><TDalign="left"><font size=-1>VODKA, l'elfe alcoolique.</font></TD><TD align="center"><IMG
src="http://fandersson.free.fr/delain/images/borg.jpg"border="2"> </TD><TD align="left"><font size=-1>L'inflexible
BJORNBORG.</font></TD><TD align="center"><IMG src="http://fandersson.free.fr/delain/images/alien1.jpg" border="2">
</TD><TDalign="left"><font size=-1>ALIEN1, le nain tempétueux.</font></TD></TR><TR><TD align="center"><IMG
src="http://fandersson.free.fr/delain/images/alien4.jpg"border="2"> </TD><TD align="left"><font size=-1>ALIEN4, l'agile
guérrier.</font></TD><TDalign="center"><IMG src="http://fandersson.free.fr/delain/images/misha.gif" border="2">
</TD><TDalign="left"><font size=-1>MISHA.</font></TD><TD align="center"><IMG
src="http://fandersson.free.fr/delain/images/mayol.gif"border="2"> </TD><TD align="left"><font
size=-1>MAYOL.</font></TD></TR><TR><TDalign="center"><IMG src="http://fandersson.free.fr/delain/images/grut.jpg"
border="2"></TD><TD align="left"><font size=-1>GRUT, l'épicier perfide.</font></TD><TD align="center"><IMG
src="http://fandersson.free.fr/delain/images/Gil_Galad.jpg"border="2"></TD><TD align="left"><font
size=-1>GIL-GALAD.</font></TD><TDalign="center"><IMG src="http://fandersson.free.fr/delain/images/orguth.jpg"
border="2"></TD><TD align="left"><font size=-1>le lieutenant ORGUTH.</font></TD></TR><TR><TD align="center"><IMG
src="http://fandersson.free.fr/delain/images/tassin.jpg"border="2"> </TD><TD align="left"><font size=-1>TASSIN, la
terreurdes abattoirs.</font></TD><TD align="center"><IMG src="http://fandersson.free.fr/delain/images/pithivier.jpg"
border="2"></TD><TDalign="left"><font size=-1>PITHIVIERS, le redoutable employé communal.</font></TD><TD
align="center"><IMGsrc="http://fandersson.free.fr/delain/images/chaudart.jpg" border="2"></TD><TD align="left"><font
size=-1>CHAUDARD,le sergent-chef quincallier.</font></TD></TR><TR><TD align="center"><IMG
src="http://fandersson.free.fr/delain/images/duron.jpg"border="2"></TD><TD align="left"><font size=-1>Du DUR, du BON,
c'estDURON...</font></TD></TR></TABLE><hr WIDTH="100%"><br />\r\n<font size=-1><br />\r\n<br />\r\nNotre mot d'ordre :
DEFENDREl'HONNEUR DE L'ARMEE...<br />\r\n<br />\r\nLA SEPTIEME COMPAGNIE FAIT PARTIE DE L'ALLIANCES DES SERIES B
(Septièmecompagnie et gendrames de Saint-Tropez).<br />\r\n<br />\r\nNotre code de conduite:<br />\r\nARTICLE 1 : Ne
jamaisattaquer un Humain sauf attitude belliqueuse, récente, hostile et agressive de sa part (même si c'est vrai que
l'Hommeest mauvais...).<br />\r\nARTICLE 2 : Ne jamais attaquer un Elf sauf attitude belliqueuse, récente, hostile et
agressivede sa part (même si c'est vrai qu'un elf c'est fourbe...).<br />\r\nARTICLE 3 : Ne jamais attaquer un Nain
saufattitude belliqueuse, récente, hostile et agressive de sa part (même si faut reconnaitre que petit comme c'est
c'esttentant...).<br />\r\nARTICLE 4 : Eviter de provoquer un conflit entre notre guilde et d'autre guildes.<br
/>\r\nLesarticles 1 à 3 priment sur l'article 4.<br />\r\nARTICLE 5 : Obligation de porter assistance à un membre de
notreguilde qui le réclame.<br />\r\nARTICLE 6 : Si jamais on a très envie, mais alors très très envie de bafouer les
artciles1,2,3 et 4 on peut!<br />\r\n<br />\r\nEN CAS DE TRAHISON AVEREE tout membre de la guilde devra avoir pour but
larédemption de l'âme du traitre qui devra donc vivre 7 nouvelles vies (et donc 7 morts) afin de connaitre le
pardon...<br/>\r\n<br />\r\nNos conditions d'admission:<br />\r\nN'ayant pas pour but d'être la guilde regroupant le
plusde membres (pour une simple question de coordination des actions), il y des conditions à remplir pour postuler.
Voicinos critères (aucun n'est éliminatoire, mais ne postuler pas si vous pensez remplir seulement quelques
critères...)<br/>\r\n-Un bon Karma (la notre est bonne pour l'instant, nous tenons à continuer...).<br />\r\n-Pas de
PK.<br/>\r\n-Une bonne renommée/Nombre de monstres tués (histoire d'évaluer votre niveau...).<br />\r\n-Avoir tué peu
dejoueurs (nous ne cherchons pas le conflit avec les autres habitants de Delain).<br />\r\nBien-sur comme toute
structurenotre guilde subi parfois quelques retards administratifs, n'oubliez donc pas que quelques points d'expérience
et/ouquelques brouzoufs distribués ça et là aux membres de la guilde peuvent permettre de faire avancer le dossier plus
rapidement...;-)<br />\r\n<br />\r\n<br />\r\nAlliances :<br />\r\n<br />\r\nAlliance des series B : avec "les
gendarmesde St-tropez"<br />\r\n<br />\r\n<br />\r\n</font>    O
 

messages:
71621    28-11-2003    Re HJ coupde gueule    Titre : Re : Re : HJ : Coup de gueule<br />\r\nExpéditeur : Bricogne<br
/>\r\nDestinataires: Altheos, Merrick, Blade,<br />\r\n<br />\r\n>Tu le fais expres Bricogne ou quoi ???<br
/>\r\n???Pourquoi ???<br />\r\n<br />\r\n>personne ne connait l'etendue de tes<br />\r\n>connaissance, et
quelqu'unconnait-il<br />\r\n>ton equipement ???<br />\r\nNon , bien que je ne le cache pas, mais si j'avais reussi
achoper une arme ou un objet extraordinaire telle la Faucheuse, la guilde aurait ete au courant.<br />\r\nEn ce moment
jecrie a hue et a dia pour recuperer mon arme D8+1 (la numero 28) que j'ai perdu lors de ma mort d'il y a 2 semaines.
Jecrie partout que j'ai perdu mon "arme fetiche". Ceux qui savent que normallement tu as la Faucheuse, ils
doiventbien rigoler quand ils voient que je me bats pour une simple D8+1.<br />\r\n<br />\r\n>veux tu dire que tu es
lepremier a<br />\r\n>partager tes infos ??? Tiens une<br />\r\n>carte ???<br />\r\nBricogne n'a aucune info
speciale.En particulier, il est une brele en cartographie donc il ne peut rien partager.<br />\r\nMarche-Neige (vue au
maximum)ou Autrui (n'a que ca a foutre) par contre ont d'excellentes cartes. Le pire c'est que je n'utilise meme pas
lescartes de MarcheNeige pour aider Bricogne. J'utilise l'automap de chacun et il m'est arrive une fois de devoir aller
aun endroit que Bricogne ne connaissait pas. J'ai tire au pif pour savoir si je passais par le nord ou par le sud,
alorsque MarcheNeige connaissait le chemin. Coup de bol les des ont donne le bon chemin et Bricogne est arrive
rapidement.<br/>\r\n<br />\r\n>cela a traine sur le forum, suite a<br />\r\n>la mort de sirius ...<br />\r\nOk,
d'accordj'accepte la critique, je me rappelle avoir lu un truc sur une arme mais je n'avais pas realise. Pour moi quand
tuparlais de l'arme je croyais que c'etait un expression litteraire pour parler de ton arme fetiche et non pas que
c'etaitELLE. M'enfin tu aurais pu dire a tes amis de la guilde avant de le dire sur forum que tu L'avais. En ce moment
encherchant ma d8+1 je dis partout mon arme magique, mon tresor ou mon arme fetiche. Les perso vont donc croire que
j'aiune arme superbe ce qui n'est rien car ce n'est qu'une d8+1, or au yeux de Bricogne, il n'a jamais vu mieux.<br
/>\r\n<br/>\r\n>c'est normal non ? D'ailleurs, c'est<br />\r\n>pour cela qu'ils m'ont tue,<br />\r\n>et qu'ils
ontete bien decus :)<br />\r\nOui d'accord mais ce qui m'a mis en colere c'est que franchement tout le monde savait que
tuavais la Faucheuse sauf Bricogne.<br />\r\n<br />\r\n>L'artefact est tombe, et a tout de<br />\r\n>suite ete
recupere...<br/>\r\n>Mais sache que celui qui l'a fait<br />\r\n>n'est pas de notre guilde,<br />\r\n>ne te
connaitpas, et ne connait<br />\r\n>que peu de monde ...<br />\r\n>Donc, pourquoi t'aurait-il fait<br
/>\r\n>confiance? C'est totalement RP...<br />\r\nDonc tu as mal joue.<br />\r\nJe suppose que l'artefact a ete
recuperepar un autre de tes perso ou bien par un ami a toi en vrai.<br />\r\nCet artefact devait rester dans la guilde.
Doncpourquoi sur le plan RP comme tu dis, il a ete pris par un autre que Blade et Blade ne s'inquiete pas. Blade aurait
dudire a Bricogne de foncer prendre l'artecfact avant que quiconque, meme un de tes personnage le prenne, quitte a se
qu'onse tape dessus pour que Bricogne fasse tout pour le recuperer.<br />\r\n<br />\r\nDonc on doit partir a la chase a
l'artecfactet tu dois dire qui etait present en vue de Blade quand il est mort pour que l'on aille les voir et voire
lestuer tous pour recuperer l'artefact. Meme si c'est un perso a toi.<br />\r\n<br />\r\nQuand j'ai joue les
mercenairesqui devaient aller tuer Blade, tu crois que sur le plan humain cela m'amusait de tuer le perso d'un pote. Et
commej'avais dis, Bricogne aurait frappe les Mercenaires pour porter secours a Blade.    Fri 28 Nov 13:09:12.541847
2003MET
 


Thanks
-- 
Olivier PRENANT                    Tel: +33-5-61-50-97-00 (Work)
6, Chemin d'Harraud Turrou           +33-5-61-50-97-01 (Fax)
31190 AUTERIVE                       +33-6-07-63-80-64 (GSM)
FRANCE                          Email: ohp@pyrenet.fr
------------------------------------------------------------------------------
Make your life a dream, make your dream a reality. (St Exupery)


Re: set search_path and pg_dumpall

From
Tom Lane
Date:
ohp@pyrenet.fr writes:
> When a serch_path has been set, pg_dumpall correctly output a alter
> database xxx set search_path to 'xxx' but *BEFORE* the schema is created
> so it doesn't work.

Hm.  It's worse than that really: in ALTER DATABASE SET, we are trying
to check the search path in the wrong context.  Consider:

regression=# create database foo;
CREATE DATABASE
regression=# alter database foo set search_path to 'fooschema';
ERROR:  schema "fooschema" does not exist

If we are not connected to database foo then we have no way to tell
whether the requested search path is valid.  Presently the backend
is checking the path against the schemas in the *current* database,
which is obviously bogus.

A closely related case is this (which also represents a scenario
where pg_dumpall will fail at the moment):

regression=# create user foo;
CREATE USER
regression=# alter user foo set search_path to 'fooschema';
ERROR:  schema "fooschema" does not exist

I am inclined to think that raising an error here isn't a good idea
either, since it's quite possible that the user's search path isn't
meant to be used in the current database.  We don't even have
any way to tell which database it is meant to be used in.

So I'm leaning to the thought that we shouldn't change pg_dumpall's
behavior, but instead should relax the backend's error checking so
that it doesn't reject these cases.  To be specific, I think that
for "ALTER DATABASE/USER SET search_path", we only want to do a
syntactic check that the search path is valid (ie, it's a list of
identifiers), and not insist that it refer to existing schemas.

The only case where checking schema existence is arguably useful is
ALTERing the current database --- but if we do that, then we still
have to do something to change pg_dumpall's behavior, and existing
pg_dumpall scripts are still broken.  So I'm content to say that we
won't check regardless of which database is the target.

Next question is how exactly to make the change.  It seems like a really
clean solution would involve adding another GucSource or GucContext
value to denote that we're trying to validate an ALTER ... SET value,
and changing the API for GUC variable assign hooks so that
assign_search_path could find out that that's what we're doing.  Should
we go to that much trouble, and if so what should the modified API be?
At the moment search_path seems to be the only GUC variable that has a
context-sensitive checking routine, so maybe a quick kluge for just this
variable is sufficient.  I have a feeling the problem may come up in the
future with other variables, though.

Comments?
        regards, tom lane


Re: set search_path and pg_dumpall

From
ohp@pyrenet.fr
Date:
Thanks for the input Tom.
INMHO, this kind of statement should'nt cause any error even if the schema
doesn't exit *yet*; because:
1) if the script comes for pg_dump[all], we KNOW that this statement is
right
2) if it's typed in psql, and the user names the wrong schema, he will
find out very quickly (benn there, done that)...

You didn't reply to the second part of my mail witch prevents me to go to
7.4.1

Regards
On Thu, 15 Jan 2004, Tom Lane wrote:

> Date: Thu, 15 Jan 2004 19:16:47 -0500
> From: Tom Lane <tgl@sss.pgh.pa.us>
> To: ohp@pyrenet.fr
> Cc: pgsql-hackers list <pgsql-hackers@postgresql.org>,
>      Peter Eisentraut <peter_e@gmx.net>
> Subject: Re: [HACKERS] set search_path and pg_dumpall
>
> ohp@pyrenet.fr writes:
> > When a serch_path has been set, pg_dumpall correctly output a alter
> > database xxx set search_path to 'xxx' but *BEFORE* the schema is created
> > so it doesn't work.
>
> Hm.  It's worse than that really: in ALTER DATABASE SET, we are trying
> to check the search path in the wrong context.  Consider:
>
> regression=# create database foo;
> CREATE DATABASE
> regression=# alter database foo set search_path to 'fooschema';
> ERROR:  schema "fooschema" does not exist
>
> If we are not connected to database foo then we have no way to tell
> whether the requested search path is valid.  Presently the backend
> is checking the path against the schemas in the *current* database,
> which is obviously bogus.
>
> A closely related case is this (which also represents a scenario
> where pg_dumpall will fail at the moment):
>
> regression=# create user foo;
> CREATE USER
> regression=# alter user foo set search_path to 'fooschema';
> ERROR:  schema "fooschema" does not exist
>
> I am inclined to think that raising an error here isn't a good idea
> either, since it's quite possible that the user's search path isn't
> meant to be used in the current database.  We don't even have
> any way to tell which database it is meant to be used in.
>
> So I'm leaning to the thought that we shouldn't change pg_dumpall's
> behavior, but instead should relax the backend's error checking so
> that it doesn't reject these cases.  To be specific, I think that
> for "ALTER DATABASE/USER SET search_path", we only want to do a
> syntactic check that the search path is valid (ie, it's a list of
> identifiers), and not insist that it refer to existing schemas.
>
> The only case where checking schema existence is arguably useful is
> ALTERing the current database --- but if we do that, then we still
> have to do something to change pg_dumpall's behavior, and existing
> pg_dumpall scripts are still broken.  So I'm content to say that we
> won't check regardless of which database is the target.
>
> Next question is how exactly to make the change.  It seems like a really
> clean solution would involve adding another GucSource or GucContext
> value to denote that we're trying to validate an ALTER ... SET value,
> and changing the API for GUC variable assign hooks so that
> assign_search_path could find out that that's what we're doing.  Should
> we go to that much trouble, and if so what should the modified API be?
> At the moment search_path seems to be the only GUC variable that has a
> context-sensitive checking routine, so maybe a quick kluge for just this
> variable is sufficient.  I have a feeling the problem may come up in the
> future with other variables, though.
>
> Comments?
>
>             regards, tom lane
>

-- 
Olivier PRENANT                    Tel: +33-5-61-50-97-00 (Work)
6, Chemin d'Harraud Turrou           +33-5-61-50-97-01 (Fax)
31190 AUTERIVE                       +33-6-07-63-80-64 (GSM)
FRANCE                          Email: ohp@pyrenet.fr
------------------------------------------------------------------------------
Make your life a dream, make your dream a reality. (St Exupery)


Re: set search_path and pg_dumpall

From
Robert Treat
Date:
I can't be the only one forsee frustration from users who typo the set
search_path statement and then can't figure out why their tables aren't
showing up... can we emit a warning that not all of the schemas in the
search path were found? 

Robert Treat 

On Fri, 2004-01-16 at 06:47, ohp@pyrenet.fr wrote:
> Thanks for the input Tom.
> INMHO, this kind of statement should'nt cause any error even if the schema
> doesn't exit *yet*; because:
> 1) if the script comes for pg_dump[all], we KNOW that this statement is
> right
> 2) if it's typed in psql, and the user names the wrong schema, he will
> find out very quickly (benn there, done that)...
> 
> You didn't reply to the second part of my mail witch prevents me to go to
> 7.4.1
> 
> Regards
> On Thu, 15 Jan 2004, Tom Lane wrote:
> 
> > Date: Thu, 15 Jan 2004 19:16:47 -0500
> > From: Tom Lane <tgl@sss.pgh.pa.us>
> > To: ohp@pyrenet.fr
> > Cc: pgsql-hackers list <pgsql-hackers@postgresql.org>,
> >      Peter Eisentraut <peter_e@gmx.net>
> > Subject: Re: [HACKERS] set search_path and pg_dumpall
> >
> > ohp@pyrenet.fr writes:
> > > When a serch_path has been set, pg_dumpall correctly output a alter
> > > database xxx set search_path to 'xxx' but *BEFORE* the schema is created
> > > so it doesn't work.
> >
> > Hm.  It's worse than that really: in ALTER DATABASE SET, we are trying
> > to check the search path in the wrong context.  Consider:
> >
> > regression=# create database foo;
> > CREATE DATABASE
> > regression=# alter database foo set search_path to 'fooschema';
> > ERROR:  schema "fooschema" does not exist
> >
> > If we are not connected to database foo then we have no way to tell
> > whether the requested search path is valid.  Presently the backend
> > is checking the path against the schemas in the *current* database,
> > which is obviously bogus.
> >
> > A closely related case is this (which also represents a scenario
> > where pg_dumpall will fail at the moment):
> >
> > regression=# create user foo;
> > CREATE USER
> > regression=# alter user foo set search_path to 'fooschema';
> > ERROR:  schema "fooschema" does not exist
> >
> > I am inclined to think that raising an error here isn't a good idea
> > either, since it's quite possible that the user's search path isn't
> > meant to be used in the current database.  We don't even have
> > any way to tell which database it is meant to be used in.
> >
> > So I'm leaning to the thought that we shouldn't change pg_dumpall's
> > behavior, but instead should relax the backend's error checking so
> > that it doesn't reject these cases.  To be specific, I think that
> > for "ALTER DATABASE/USER SET search_path", we only want to do a
> > syntactic check that the search path is valid (ie, it's a list of
> > identifiers), and not insist that it refer to existing schemas.
> >
> > The only case where checking schema existence is arguably useful is
> > ALTERing the current database --- but if we do that, then we still
> > have to do something to change pg_dumpall's behavior, and existing
> > pg_dumpall scripts are still broken.  So I'm content to say that we
> > won't check regardless of which database is the target.
> >
> > Next question is how exactly to make the change.  It seems like a really
> > clean solution would involve adding another GucSource or GucContext
> > value to denote that we're trying to validate an ALTER ... SET value,
> > and changing the API for GUC variable assign hooks so that
> > assign_search_path could find out that that's what we're doing.  Should
> > we go to that much trouble, and if so what should the modified API be?
> > At the moment search_path seems to be the only GUC variable that has a
> > context-sensitive checking routine, so maybe a quick kluge for just this
> > variable is sufficient.  I have a feeling the problem may come up in the
> > future with other variables, though.
> >
> > Comments?
> >
> >             regards, tom lane
> >
> 
> -- 
> Olivier PRENANT                    Tel: +33-5-61-50-97-00 (Work)
> 6, Chemin d'Harraud Turrou           +33-5-61-50-97-01 (Fax)
> 31190 AUTERIVE                       +33-6-07-63-80-64 (GSM)
> FRANCE                          Email: ohp@pyrenet.fr
> ------------------------------------------------------------------------------
> Make your life a dream, make your dream a reality. (St Exupery)
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 6: Have you searched our list archives?
> 
>                http://archives.postgresql.org

-- 
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL



Re: set search_path and pg_dumpall

From
Tom Lane
Date:
Robert Treat <xzilla@users.sourceforge.net> writes:
> I can't be the only one forsee frustration from users who typo the set
> search_path statement and then can't figure out why their tables aren't
> showing up... can we emit a warning that not all of the schemas in the
> search path were found? 

Since no one else commented, I've followed your suggestion.  As of CVS
tip, you get a NOTICE not ERROR in this case:

regression=# set search_path = public,z;
ERROR:  schema "z" does not exist
regression=# create database foo;
CREATE DATABASE
regression=# alter database foo set search_path = public,z;
NOTICE:  schema "z" does not exist
ALTER DATABASE
regression=# select datconfig from pg_database where datname = 'foo';        datconfig
---------------------------{"search_path=public, z"}
(1 row)

If a bogus entry is present in the established search_path value, it's
just ignored (this was true already to handle "$user"):

regression=# \c foo
You are now connected to database "foo".
foo=# show search_path;search_path
-------------public, z
(1 row)

foo=# select current_schemas(true);  current_schemas
---------------------{pg_catalog,public}
(1 row)
        regards, tom lane