Bug #750: dumping/restoring database with custom languages does not work

Mathieu Arnold (m(at)absolight(dot)fr) reports a bug with a severity of 2
The lower the number the more severe it is.

Short Description
dumping/restoring database with custom languages does not work

Long Description
When adding a plpgsql to one of my database, I ran pg_dump, and I discovered that the lines werent ordrered the right way.
After the drop language there is a \connect - pgsql, which should be before...

Sample Code
$ pg_dump -c mat
--
-- Selected TOC Entries:
--
$ createlang -U pgsql plpgsql mat
$ pg_dump -c mat
--
-- Selected TOC Entries:
--
DROP PROCEDURAL LANGUAGE 'plpgsql';
\connect - pgsql

DROP FUNCTION "plpgsql_call_handler" ();
--
-- TOC Entry ID 2 (OID 64384)
--
-- Name: "plpgsql_call_handler" () Type: FUNCTION Owner: pgsql
--

CREATE FUNCTION "plpgsql_call_handler" () RETURNS opaque AS '$libdir/plpgsql', 'plpgsql_call_handler' LANGUAGE 'C';

--
-- TOC Entry ID 3 (OID 64385)
--
-- Name: plpgsql Type: PROCEDURAL LANGUAGE Owner:
--

CREATE TRUSTED PROCEDURAL LANGUAGE 'plpgsql' HANDLER "plpgsql_call_handler" LANCOMPILER '';

$ pg_dump -c mat |psql
ERROR: Only users with Postgres superuser privilege are permitted to drop procedural languages
You are now connected as new user pgsql.
DROP
CREATE
ERROR: Language plpgsql already exists
$ echo select version\(\)|psql
version
-----------------------------------------------------------------------
PostgreSQL 7.2.2 on i386-portbld-freebsd4.6.1, compiled by GCC 2.95.3
(1 row)

No file was uploaded with this report