Re: BUG #15382: Error create dictionary in pg_dump

Thanks!

Understood why. But I did not know what doing. Particularly, I need for
upgrade my cluster to new version (9.5 to 10) and i used pg_upgrade
command. Upgrade in turn used pg_dump, pg_restore combination and I can't
affect for this. Can you help me? May be exists anyone flag in pg_upgrade
method, whis will correct this problem, or ignored him.

пт, 14 сент. 2018 г. в 3:30, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:

> =?utf-8?q?PG_Bug_reporting_form?= <noreply(at)postgresql(dot)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
>

--
С уважением, Ковальчук Андрей.