Bruce Momjian wrote: > Bruce Momjian wrote: > > Tom Lane wrote: > > > Bruce Momjian <br...@momjian.us> writes: > > > > I installed PL/pgSQL by default via initdb with the attached patch. The > > > > only problem is that pg_dump still dumps out the language creation: > > > > CREATE PROCEDURAL LANGUAGE plpgsql; > > > > ALTER PROCEDURAL LANGUAGE plpgsql OWNER TO postgres; > > > > What is odd is that I used the same process that initdb uses to create > > > > other objects. Does anyone know why this is happening? > > > > > > I think pg_dump pays attention to what schema the objects are in, > > > and that's most likely creating them in PUBLIC. Try adding > > > "set search_path = pg_catalog". > > > > > > It's not impossible that we'll have to tweak pg_dump a bit; it's > > > never had to deal with languages that shouldn't be dumped ... > > > > I found that pg_dump tests for pg_language.lanispl == true, which is > > true for all the stored procedure languages. I can easily special case > > plpgsql, or check for FirstNormalObjectId, though I don't see that used > > in pg_dump currently. > > > > A more difficult issue is whether we should preserve the fact that > > plpgsql was _removed_ in the pg_dump output, i.e, if someone removes > > plpgsql from a database, do we issue a DROP LANGUAGE in pg_dump? I > > don't remember us having to deal with anything like this before. > > OK, the attached patch installs plpgsql by default from initdb, and > supresses the dumping of CREATE LANGUAGE in 8.5 and in 8.3/8.4 if binary > upgrade is used (because you know you are upgrading to a release that > has plpgsql installed by default). The 8.3/8.4 is necessary so the > schema load doesn't generate any errors and cause pg_migrator to exit.
Applied. -- Bruce Momjian <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers