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

Re: erroneous restore into pg_catalog schema

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Dimitri Fontaine <dimitri(at)2ndQuadrant(dot)fr>
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:09:29
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
Dimitri Fontaine <dimitri(at)2ndQuadrant(dot)fr> writes:
> Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
>> I think maybe what we should do is have namespace.c retain an explicit
>> notion that "the first schema listed in search_path didn't exist", and
>> then throw errors if any attempt is made to create objects without an
>> explicitly specified namespace.

> I don't much like this.

>   SET search_path TO dontexist, a, b;
>   CREATE TABLE foo();

> And the table foo is now in a (provided it exists). Your proposal would
> break that case, right?

"Break"?  You can't possibly think that's a good idea.

> The problem is that the search_path could come
> from too many places: postgresql.conf, ALTER ROLE, ALTER DATABASE etc.
> And I have seen roles setup with some search_path containing schema that
> will only exist in some of the database they can connect to

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.

BTW, although Erik claimed this behaved more sanely in 9.2, a closer
look at the commit logs says that the bogus commit shipped in 9.2,
so AFAICS it's broken there too.  But earlier releases would have
rejected the SET as expected.  I think we should assume that existing
code is expecting the pre-9.2 behavior.

			regards, tom lane

In response to


pgsql-hackers by date

Next:From: Gurjeet SinghDate: 2013-01-13 21:12:18
Subject: count(*) of zero rows returns 1
Previous:From: Andres FreundDate: 2013-01-13 21:06:37
Subject: Re: [PATCH] unified frontend support for pg_malloc et al and palloc/pfree mulation (was xlogreader-v4)

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