Re: Core Extensions relocation - Mailing list pgsql-hackers

From Dimitri Fontaine
Subject Re: Core Extensions relocation
Date
Msg-id 87k4cuaq52.fsf@hi-media-techno.com
Whole thread Raw
In response to Core Extensions relocation  (Greg Smith <greg@2ndquadrant.com>)
List pgsql-hackers
Hi,

Greg Smith <greg@2ndquadrant.com> writes:
> Following up on the idea we've been exploring for making some extensions
> more prominent, attached is the first rev that I think may be worth
> considering seriously.  Main improvement from the last is that I reorganized
> the docs to break out what I decided to tentatively name "Core Extensions"
> into their own chapter.  No longer mixed in with the rest of the contrib
> modules, and I introduce them a bit differently.   If you want to take a
> quick look at the new page, I copied it to
> http://www.2ndquadrant.us/docs/html/extensions.html

Thanks a lot for working on this!

I have two remarks here.  First, I think that the “core extensions” (+1
for this naming) should not be found in a documentation appendix, but in
the main documentation, as a new Chapter in Part II where we list data
types and operators and system functions.  Between current chapters 9
and 10 would be my vote.

Then, I think the angle to use to present “core extensions” would be
that those are things maintained like the core server, but that you
might not need at all.  There's no SQL level feature that rely on them,
it's all “extra”, but it's there nonetheless, because you might need it.

Other than that, +1 for your patch.  I'd stress out that I support your
idea to split the extensions at the source level, I think that's really
helping to get the message out: that is trustworthy and maintained code.

Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr     PostgreSQL : Expertise, Formation et Support


pgsql-hackers by date:

Previous
From: Heikki Linnakangas
Date:
Subject: Small SSI issues
Next
From: Gurjeet Singh
Date:
Subject: Re: Creating new remote branch in git?