Re: BUG #15382: Error create dictionary in pg_dump
От | Tom Lane |
---|---|
Тема | Re: BUG #15382: Error create dictionary in pg_dump |
Дата | |
Msg-id | 11550.1536859804@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | BUG #15382: Error create dictionary in pg_dump (PG Bug reporting form <noreply@postgresql.org>) |
Ответы |
Re: BUG #15382: Error create dictionary in pg_dump
|
Список | pgsql-bugs |
=?utf-8?q?PG_Bug_reporting_form?= <noreply@postgresql.org> writes: > Dump is creates, but have one trouble. Result of using pg_resote command: > pg_restore: [архиватор (БД)] could not execute query: ОШИБКА (Error): > словарь текстового поиска (text search dictionary) "ispell_apteka25" не > существует (not exists) > Выполнялась команда (running command): CREATE TEXT SEARCH DICTIONARY > "public"."thesaurus_apteka25" ( > TEMPLATE = "pg_catalog"."thesaurus", > dictfile = 'apteka25', dictionary = 'ispell_apteka25' ); Yeah, this is a consequence of the security changes we made awhile back to run dump and restore under restrictive search_path settings. You need to explicitly schema-qualify that sub-dictionary name, since it isn't in the pg_catalog schema. Unfortunately, since dictionary parameters are just strings without a lot of fixed semantics to them, pg_dump can't really fix this for you --- it doesn't know that that parameter refers to a database object, or which database object. > If i change argument dictionary for this note to: dictionary = > 'public.ispell_apteka25' - it's now ok! Yup, that's what you have to do. Note that this is a good thing anyway, independently of pg_dump, because your old definition could have failed if the thesaurus dictionary were invoked by any application running under a nondefault search_path. regards, tom lane
В списке pgsql-bugs по дате отправления: