| Lists: | pgsql-bugs |
|---|
| From: | laurenz(dot)albe(at)wien(dot)gv(dot)at |
|---|---|
| To: | pgsql-bugs(at)postgresql(dot)org |
| Subject: | BUG #6318: pg_dump for non-template languages is broken |
| Date: | 2011-12-02 11:06:41 |
| Message-ID: | E1RWQwz-0005Ug-06@wrigleys.postgresql.org |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Lists: | pgsql-bugs |
The following bug has been logged on the website:
Bug reference: 6318
Logged by: Laurenz Albe
Email address: laurenz(dot)albe(at)wien(dot)gv(dot)at
PostgreSQL version: 9.1.1
Operating system: Linux (RHEL 3)
Description:
How to reproduce:
postgres=# CREATE DATABASE dumpme;
postgres=# \c dumpme postgres
dumpme=# CREATE LANGUAGE mylang HANDLER plpgsql_call_handler INLINE
plpgsql_inline_handler VALIDATOR plpgsql_validator;
dumpme=# \q
$ pg_dump -C -F p -f dumpme.sql dumpme
$ psql -c 'DROP DATABASE dumpme'
$ psql -f dumpme.sql
[...]
psql:dumpme.sql:32: ERROR: unsupported language "mylang"
HINT: The supported languages are listed in the pg_pltemplate system
catalog.
psql:dumpme.sql:35: ERROR: language "mylang" does not exist
[...]
The reason is that the dump contains:
--
-- Name: mylang; Type: PROCEDURAL LANGUAGE; Schema: -; Owner: advpg
--
CREATE OR REPLACE PROCEDURAL LANGUAGE mylang;
ALTER PROCEDURAL LANGUAGE mylang OWNER TO advpg;
Yours,
Laurenz Albe
| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | laurenz(dot)albe(at)wien(dot)gv(dot)at |
| Cc: | pgsql-bugs(at)postgresql(dot)org |
| Subject: | Re: BUG #6318: pg_dump for non-template languages is broken |
| Date: | 2011-12-02 17:28:11 |
| Message-ID: | 19869.1322846891@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Lists: | pgsql-bugs |
laurenz(dot)albe(at)wien(dot)gv(dot)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
| From: | "Albe Laurenz" <laurenz(dot)albe(at)wien(dot)gv(dot)at> |
|---|---|
| To: | "Tom Lane *EXTERN*" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | <pgsql-bugs(at)postgresql(dot)org> |
| Subject: | Re: BUG #6318: pg_dump for non-template languages is broken |
| Date: | 2011-12-03 10:55:31 |
| Message-ID: | D960CB61B694CF459DCFB4B0128514C2049FCE7A@exadv11.host.magwien.gv.at |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Lists: | pgsql-bugs |
Tom Lane wrote:
>> 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:
> An actual add-on procedural language would not fall foul of this.
Oh I see. Sorry for the noise.
Yours,
Laurenz Albe