Re: Quick Extensions Question

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Dimitri Fontaine <dimitri(at)2ndquadrant(dot)fr>, "David E(dot) Wheeler" <david(at)kineticode(dot)com>, pgsql-hackers Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Quick Extensions Question
Date: 2011-03-04 16:19:48
Message-ID: 28976.1299255588@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Fri, Mar 4, 2011 at 10:43 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2011-03-04 16:38:14 Re: Quick Extensions Question
Previous Message Robert Haas 2011-03-04 16:00:22 Re: Quick Extensions Question