Skip site navigation (1) Skip section navigation (2)

Re: Extensions User Design

From: Peter Eisentraut <peter_e(at)gmx(dot)net>
To: pgsql-hackers(at)postgresql(dot)org
Cc: Andrew Dunstan <andrew(at)dunslane(dot)net>, "David E(dot) Wheeler" <david(at)kineticode(dot)com>, Josh Berkus <josh(at)agliodbs(dot)com>, Dimitri Fontaine <dfontaine(at)hi-media(dot)com>
Subject: Re: Extensions User Design
Date: 2009-06-29 12:48:19
Message-ID: 200906291548.19839.peter_e@gmx.net (view raw or flat)
Thread:
Lists: pgsql-hackers
On Thursday 25 June 2009 01:09:17 Andrew Dunstan wrote:
> Well, I think in our case that would be going too far. I think there is
> a very good case for keeping a few key extensions in core both as
> exemplars and to make it easy to validate the extension mechanism
> itself. There have been suggestions in the past about throwing a bunch
> of things overboard, sometimes out of a passion for neatness more than
> anything else ISTM, but there have been good arguments against as well,
> particularly in the case of the PLs, which are tied so closely to the
> backend.

Another thing we might want to consider once we have a robust extension 
mechanism is to move some things out of the backend into extensions.  
Candidates could be uuid, legacy geometry types, inet/cidr, for example.  
These extensions would still be available and probably installed by default, 
but they need not be hardcoded into the backend.  But a policy of shipping 
zero extensions with the postgresql tarball obviously leaves very little 
flexibility to do any sort of thing like this.

In response to

Responses

pgsql-hackers by date

Next:From: Richard HuxtonDate: 2009-06-29 13:01:33
Subject: Re: Extensions User Design
Previous:From: Tsutomu YamadaDate: 2009-06-29 10:52:50
Subject: Re: Proposal: More portable way to support 64bit platforms

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group