On Tue, Jul 25, 2017 at 10:31 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> 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_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.
Is this assumption, like, documented someplace?
I tend to think it's pretty bad when users can execute SQL and then
pg_dump doesn't work. I mean, if you play with the contents of
pg_catalog, then I'm not sure how much we can guarantee, but I don't
see how a user would know that there's anything wrong with Tushar's
SQL command.
I would be on board with the idea that you (or anyone, really) doesn't
want to fix this because it's a fairly unimportant issue, but I balk
at the notion that nothing is wrong here, because to me that looks
busted.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company