Re: Extensions User Design

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.