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

Re: Extensions User Design

From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: "David E(dot) Wheeler" <david(at)kineticode(dot)com>
Cc: Josh Berkus <josh(at)agliodbs(dot)com>, Dimitri Fontaine <dfontaine(at)hi-media(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Extensions User Design
Date: 2009-06-24 22:41:03
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers

David E. Wheeler wrote:
> On Jun 24, 2009, at 3:09 PM, 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.
> Exemplars are good if they behave in the same way as non-core 
> extensions. So it might be good for the core to maintain contrib 
> extensions, although I would urge them to keep the size down quite 
> low, and to be very conservative about adding new extensions. Part of 
> the issue Perl ran into is that it was too liberal about adding new 
> stuff to core, especially modules with large dependency trees. 
> Anything in core should be kept very simple, both to avoid bloat and 
> to minimize the maintenance overhead for the core team.

We have been conservative about this in the past and there is no reason 
to expect we will not be in the future. If anything, we are likely to 
become more so.



In response to


pgsql-hackers by date

Next:From: Tom LaneDate: 2009-06-24 23:34:34
Subject: Re: building without perl
Previous:From: David E. WheelerDate: 2009-06-24 22:18:30
Subject: Re: Extensions User Design

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