Re: Quick Extensions Question - Mailing list pgsql-hackers

On Fri, Mar 4, 2011 at 11:19 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> 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.

OK.  Assuming that'll still be the case even when a 9.1 pg_dump is
used on a 9.0 database, that seems OK.

>>> 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.

Well, if we're not going remove them altogether, then my vote would be
to leave them unchanged (i.e. they'll still emit CREATE LANGUAGE) and
stick a big deprecation warning on them.  It isn't necessary to have
every SQL command available as a standalone executable.  AFAICT,
createdb and dropdb are useful primarily because they do the necessary
dance of connecting to some other database in order to operate on a
different database; and vacuumdb is useful because you can make it
process all databases in a loop.  Those things can be done with psql
too, but it's a bit more complicated.  However, neither argument
applies to createlang/droplang.  Installing and removing extensions
and languages is also presumably a pretty infrequent operation, which
is another reason to think that we probably don't need a separate tool
for it.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company