| 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: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| 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 | Date | Subject | |
|---|---|---|---|
| Next Message | Albe Laurenz | 2011-12-03 10:55:31 | Re: BUG #6318: pg_dump for non-template languages is broken |
| Previous Message | Magnus Hagander | 2011-12-02 15:41:12 | Re: BUG #6314: The like command does not handle a long string of special chars |