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
|
Список | 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 по дате отправления: