Re: erroneous restore into pg_catalog schema
От | Tom Lane |
---|---|
Тема | Re: erroneous restore into pg_catalog schema |
Дата | |
Msg-id | 7481.1358111369@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: erroneous restore into pg_catalog schema (Dimitri Fontaine <dimitri@2ndQuadrant.fr>) |
Ответы |
Re: erroneous restore into pg_catalog schema
Re: erroneous restore into pg_catalog schema Re: erroneous restore into pg_catalog schema |
Список | pgsql-hackers |
Dimitri Fontaine <dimitri@2ndQuadrant.fr> writes: > Tom Lane <tgl@sss.pgh.pa.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
В списке pgsql-hackers по дате отправления: