Re: Another thought about search_path semantics
От | Tom Lane |
---|---|
Тема | Re: Another thought about search_path semantics |
Дата | |
Msg-id | 22181.1396635223@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Another thought about search_path semantics (Andres Freund <andres@2ndquadrant.com>) |
Ответы |
Re: Another thought about search_path semantics
|
Список | pgsql-hackers |
Andres Freund <andres@2ndquadrant.com> writes: > On 2014-04-04 13:58:53 -0400, Tom Lane wrote: >> Hm ... doesn't fix the problem for existing dump files, which are going to >> say "search_path = foo, pg_catalog". However, we could modify it a bit, >> so that the marker is put on schemas that can be skipped if missing for >> creation purposes. Then the default could look like "search_path = >> !$user, public", while we still get safe behavior for pg_dump's commands. > Unfortunately the curren tsearch_path is probably enshrined in a couple > of thousand postgresql.confs... Uncommented? Anyway, we never have and never will promise that you don't have to revisit your postgresql.conf during a major version upgrade. > How about simply refusing to create anything in pg_catalog unless it's > explicitly schema qualified? Looks a bit nasty to implement but doable? That's what happens already. The point is to do better. What we want for pg_dump's case is to get a complaint that schema foo doesn't exist, *not* an attempt to create in pg_catalog. That's what you got (though at the SET command not the CREATE command) in all versions before 9.2. regards, tom lane
В списке pgsql-hackers по дате отправления: