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

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

In response to

Responses

Browse pgsql-hackers by date

  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