Re: pg_dump and languages

Поиск
Список
Период
Сортировка
От Adrian Klaver
Тема Re: pg_dump and languages
Дата
Msg-id 200411261659.51355.aklaver@comcast.net
обсуждение исходный текст
Ответ на Re: pg_dump and languages  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-general
On Friday 26 November 2004 03:11 pm, Tom Lane wrote:
> Adrian Klaver <aklaver@comcast.net> writes:
> > Sorry should have been more explicit. The dump loaded functions depending
> > on plsh before the function that created the language. In fact it did not
> > instalI the language at all.
>
> Ah.  Looking back at your first message, I see you'd installed plsh into
> the pg_catalog schema rather than a user schema.  pg_dump specifically
> doesn't dump anything that appears in pg_catalog; it assumes all of that
> stuff is supplied by the system.  So the above is expected behavior.
>
> I haven't looked at plsh, but if it installs stuff directly into
> pg_catalog, I'd call that a mistake.  At least it shouldn't be the
> default behavior.
>
> (Note for pedantry's sake: a language doesn't really belong to any
> particular schema; but its support functions do, and pg_dump treats
> the language as belonging to the same schema as the support functions.)
>
>             regards, tom lane
>
> ---------------------------(end of broadcast)---------------------------
> TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org
Problem solved. The language handler function was in both the pg_catalog and
public schema. The pg_catalog version was masking the public version.
Removing the pg_catalog version allowed the pg_dump program to sort things
out properly and the restore completed with out a problem. Thanks for the
insight.
--
Adrian Klaver
aklaver@comcast.net

В списке pgsql-general по дате отправления:

Предыдущее
От: Kamil Kaczkowski
Дата:
Сообщение: Re: row-level deadlock problem
Следующее
От: Tom Lane
Дата:
Сообщение: Re: row-level deadlock problem