Re: Another thought about search_path semantics
От | Tom Lane |
---|---|
Тема | Re: Another thought about search_path semantics |
Дата | |
Msg-id | 27789.1396647116@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Another thought about search_path semantics (Andres Freund <andres@2ndquadrant.com>) |
Список | pgsql-hackers |
Andres Freund <andres@2ndquadrant.com> writes: > On 2014-04-04 17:24:00 -0400, Tom Lane wrote: >> Maybe not many, but pg_dump itself certainly can try to do that. >> (Most of the time, pg_dump won't dump things in pg_catalog, but there >> are exceptions, eg --binary-upgrade dump of an extension containing >> objects in pg_catalog.) > If we're not backpatching, fixing that seems easy enough? Not especially. As I said, pg_dump believes that setting search_path is an appropriate way to control where things get created, and that's wired into its structure pretty deeply. I would have exactly zero faith in a hack that tried to change that just for objects in pg_catalog. In any case, it's not clear that the case can't arise in pre-existing dump files, even if you discount --binary-upgrade cases. > I don't like my own suggestion, which isn't a good sign, but I haven't > heard anything I like more :(. Don't see why you don't find what I suggested to be just a small variant on it. regards, tom lane
В списке pgsql-hackers по дате отправления: