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 |
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 |