Re: Quick Extensions Question - Mailing list pgsql-hackers

From David E. Wheeler
Subject Re: Quick Extensions Question
Date
Msg-id CCDF5387-7839-4171-9270-49CF77299266@kineticode.com
Whole thread Raw
In response to Re: Quick Extensions Question  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Quick Extensions Question
List 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_superuseror 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
addinga createext command or something, and deprecating createlang, but I suspect it's a bit late in the dev cycle for
9.1.

Best,

David



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: Open unmatch source file when step into parse_analyze() in Eclipse?
Next
From: "David E. Wheeler"
Date:
Subject: Re: Quick Extensions Question