From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | tushar <tushar(dot)ahuja(at)enterprisedb(dot)com> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Create language syntax is not proper in pg_dumpall and not working using pg_upgrade |
Date: | 2017-07-25 14:31:33 |
Message-ID: | 5402.1500993093@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
tushar <tushar(dot)ahuja(at)enterprisedb(dot)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_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.)
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
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Dunstan | 2017-07-25 14:37:50 | Re: pl/perl extension fails on Windows |
Previous Message | Mat Arye | 2017-07-25 14:30:33 | Re: Fwd: Syncing sql extension versions with shared library versions |