Re: Quick Extensions Question

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

On Mar 4, 2011, at 7:43 AM, Tom Lane wrote:

>> Well it's easy to read that the other way round. Is superuser = true
>> means that I need to be a superuser or does it mean that the script will
>> get run as superuser no matter what? Not a huge problem, but still.
>> What about using the PL terminology here, and calling the property
>> 'trusted' (default false, so you have to be a superuser to load them)?
>
> Hmm. I see your point, but "trusted" seems like it could just as easily
> be misunderstood. Anybody have any other opinions about the color of
> that bikeshed?

The trusted/untrusted differentiation confuses me every single time I try to remember which is which. So how about requires_superuser or install_as_superuser?

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

+1 to CREATE OR REPLACE EXTENSION.

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

ISTM that at this late stage nothing about it should change except the command it issues to the database. I'm all for adding a createext command or something, and deprecating createlang, but I suspect it's a bit late in the dev cycle for 9.1.

Best,

David

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message David E. Wheeler 2011-03-04 16:50:06 Re: Quick Extensions Question
Previous Message Robert Haas 2011-03-04 16:42:39 Re: Open unmatch source file when step into parse_analyze() in Eclipse?