Tom Lane <t...@sss.pgh.pa.us> writes: > Robert Haas <robertmh...@gmail.com> writes: >> I am still of the opinion that changing this was a bad idea for >> exactly this reason. We could perhaps ameliorate this problem by >> implementing CREATE OR REPLACE for languages and emitting that >> instead; then the command in the dump would be a noop. > > Not really going to help for existing dumps (nor future dumps made > with pre-9.0 pg_dump versions). > > However, the case that is probably going to be the most pressing is > pg_upgrade, which last I heard insists on no errors during the restore > (and I think that's a good thing). That uses the new version's pg_dump > so a fix involving new syntax would cover it.
Not sure how helpful I'll be there, but I can't help placing the extension's proposal again. If we had extensions here, plpgsql would be a core maintained extension, made available by CREATE EXTENSION in the database (which initdb would do in templates), then have the language installed by means of issuing an INSTALL EXTENSION command. Now, what would help would be to have that support and have CREATE LANGUAGE foo; be kept for compatibility only and issue INSTALL EXTENSION foo; instead. For those still with me, the choice to have plpgsql available by default would then boil down to have initdb do the CREATE EXTENSION in the template database, the database owner would still have to run the INSTALL EXTENSION. So now --load-language is INSTALL EXTENSION and just works as intended. And older dumps are doing CREATE LANGUAGE plpgsql; which is converted to INSTALL EXTENSION plpgsql;, which just works only because the extension is made available by default. So that if there's a CREATE LANGUAGE plpythonu, say, installing this extension will only succeed when INSTALL EXTENSION plpythonu; has been done either in the template1 database before creating the target database, or in the target database itself. So now we have "smart" success and failure modes falling from the proposed model. I'll dare not say "Hope This Helps" as I realize I failed to provide any code for implementing the extension management proposal. But got back to acceptable sleeping patterns and should be able to get back on the topic later this year, unless (please) beaten to it :) Regards, -- dim -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers