Re: BUG #6318: pg_dump for non-template languages is broken
В списке pgsql-bugs по дате отправления:
| От | Tom Lane |
|---|---|
| Тема | Re: BUG #6318: pg_dump for non-template languages is broken |
| Дата | |
| Msg-id | 19869.1322846891@sss.pgh.pa.us обсуждение исходный текст |
| Ответ на | BUG #6318: pg_dump for non-template languages is broken (laurenz.albe@wien.gv.at) |
| Список | pgsql-bugs |
laurenz.albe@wien.gv.at writes:
> dumpme=# CREATE LANGUAGE mylang HANDLER plpgsql_call_handler INLINE
> plpgsql_inline_handler VALIDATOR plpgsql_validator;
I don't think this is a particularly interesting use-case. The reason
it doesn't work for you is that it's depending on support functions
that are in pg_catalog, and as the comment in pg_dump.c says:
/*
* 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_catalog schema, as is
* standard in 8.1 and up, then we won't have loaded them. (In this case
* we will emit a parameterless CREATE LANGUAGE command, which will
* require PL template knowledge in the backend to reload.)
*/
An actual add-on procedural language would not fall foul of this.
regards, tom lane
В списке pgsql-bugs по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера