Re: [HACKERS] Create language syntax is not proper in pg_dumpall and not working using pg_upgrade

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: [HACKERS] Create language syntax is not proper in pg_dumpall and not working using pg_upgrade
Дата
Msg-id 5402.1500993093@sss.pgh.pa.us
обсуждение исходный текст
Ответ на [HACKERS] Create language syntax is not proper in pg_dumpall and not workingusing pg_upgrade  (tushar <tushar.ahuja@enterprisedb.com>)
Ответы Re: [HACKERS] Create language syntax is not proper in pg_dumpall andnot working using pg_upgrade  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
tushar <tushar.ahuja@enterprisedb.com> writes:
> postgres=# CREATE LANGUAGE alt_lang1 HANDLER plpgsql_call_handler;
> CREATE LANGUAGE

pg_dump doesn't really support that scenario, and I don't feel any
great need to make it do so.  Per the comment in dumpProcLang:
 * Try to find the support function(s).  It is not an error if we don't * find them --- if the functions are in the
pg_catalogschema, as is * standard in 8.1 and up, then we won't have loaded them. (In this case * we will emit a
parameterlessCREATE LANGUAGE command, which will * require PL template knowledge in the backend to reload.)
 

So the assumption is basically that PLs that don't have pg_pltemplate
entries will not keep their support functions in pg_catalog.  I think
there are exceptions to handle languages+support functions that are
wrapped into extensions ... but you didn't do that either.
        regards, tom lane



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

Предыдущее
От: Mat Arye
Дата:
Сообщение: Re: Fwd: [HACKERS] Syncing sql extension versions with shared library versions
Следующее
От: Andrew Dunstan
Дата:
Сообщение: Re: [HACKERS] pl/perl extension fails on Windows