Skip site navigation (1) Skip section navigation (2)

Re: erroneous restore into pg_catalog schema

From: Dimitri Fontaine <dimitri(at)2ndQuadrant(dot)fr>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "Erik Rijkers" <er(at)xs4all(dot)nl>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: erroneous restore into pg_catalog schema
Date: 2013-01-13 21:18:15
Message-ID: m2k3rgye7c.fsf@2ndQuadrant.fr (view raw or flat)
Thread:
Lists: pgsql-hackers
Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
> "Break"?  You can't possibly think that's a good idea.

I don't think it is. It's been used as a hack mainly before we had
per-user and per-database settings, from what I've seen.

> Right, that is the argument for ignoring missing schemas, and I think it
> is entirely sensible for *search* activities.  But allowing *creation*
> to occur in an indeterminate schema is a horrid idea.

It's not so much indeterminate for the user, even if I understand why
you say that. Creating new schemas is not done lightly in such cases…

But well, the solution is simple enough in that case. Use the newer form

  ALTER ROLE foo IN DATABASE db1 SET search_path TO some, value;

So I'm fine with that change in fact. Is it possible to extend the
release notes to include so many details about it, as I don't think
anyone will get much excited to report that as a HINT when the
conditions are met… (although it might be simple enough thanks to the
pg_setting view).

Regards,
-- 
Dimitri Fontaine
http://2ndQuadrant.fr     PostgreSQL : Expertise, Formation et Support


In response to

pgsql-hackers by date

Next:From: Erik RijkersDate: 2013-01-13 21:23:30
Subject: Re: erroneous restore into pg_catalog schema
Previous:From: Tom LaneDate: 2013-01-13 21:16:10
Subject: Re: [PATCH] unified frontend support for pg_malloc et al and palloc/pfree mulation (was xlogreader-v4)

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group