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