Re: Quick Extensions Question - Mailing list pgsql-hackers

Robert Haas <robertmhaas@gmail.com> writes:
> On Fri, Mar 4, 2011 at 10:43 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> I've thought of two other issues that need some discussion before we
>> can get very far with this:
>> 
>> 1. What should pg_dump do with the preinstalled extension plpgsql?
>> We could put in a hardwired hack to not dump it, on the assumption that
>> it will be preinstalled in the destination database, but that seems a
>> bit ugly.  When we decided to preinstall the language, we made pg_dump
>> emit CREATE OR REPLACE LANGUAGE so that the dump script would not fail
>> if the language was preinstalled.  We don't have an equivalent command
>> for extensions, though.  We can either invent one, or put a kluge into
>> pg_dump.  Although I'm on record as generally disliking CREATE IF NOT
>> EXISTS, I think that having pg_dump emit "CREATE EXTENSION IF NOT EXISTS
>> foo" might be the best solution here.  The reason why is that unlike the
>> case with other sorts of objects, you typically want the latest version
>> of an extension installed, not the one that was present in the source
>> database; so the dump script shouldn't be trying to force a particular
>> version to be installed, which is the semantics I'd expect of CREATE OR
>> REPLACE EXTENSION.

> This is a going to make it hard to restore a 9.0 dump into a 9.1
> database, isn't it?

Not really.  The 9.0 dump will contain "CREATE OR REPLACE LANGUAGE
plpgsql", which will do nothing because it's already installed, same
as before.

>> 2. What shall we do with createlang?  Presumably it should start
>> emitting CREATE EXTENSION not CREATE LANGUAGE, at which point it's
>> really a general purpose extension installer not a PL installer.
>> To what extent should we reflect that repurposing in the documentation?
>> I think changing the name would be going too far: it would break
>> existing scripts for little return.  But it might seem a little weird
>> to read "createlang -- install an extension" in the table of contents.
>> Thoughts?

> Maybe we should just get rid of it.  It's not really adding any value
> that I can see.

Hmm.  Personally I do use createdb/dropdb but never createlang/droplang;
but I'm well aware that my usage may not be typical.  I'm a bit hesitant
to just go and drop these without any warning.  I could see deprecating
them for a release or two and then dropping them ... but that doesn't
solve the problem of what to do with them in 9.1.
        regards, tom lane