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. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
