Re: BUG #6318: pg_dump for non-template languages is broken

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

In response to

Responses

Browse pgsql-bugs by date

  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