Re: Core Extensions relocation

Dimitri Fontaine <dimitri@2ndquadrant.fr>

From: Dimitri Fontaine <dimitri@2ndQuadrant.fr>

To: Thom Brown <thom@linux.com>

Cc: Greg Smith <greg@2ndquadrant.com>, pgsql-hackers@postgresql.org

Date: 2011-11-14T22:34:12Z

Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

Updates to contrib/isn ISBN tables.
- 6d1af7b21807 9.1.0 cited
Add a "LIKE = typename" clause to CREATE TYPE for base types. This allows
- 3f936aacc057 8.4.0 cited

Thom Brown <thom@linux.com> writes:
> I'm all for removing all mention of "modules".  It's ambiguous and
> used inconsistently.

The module is the shared library object.  It should be possible to use
that consistently.  And I have some plans on my TODO list about them
anyway, so making them disappear from the manual would not serve my
later plans :)

> And auto_explain appears in your new "Core Extensions" section, but
> it's not an extension in the terminology PostgreSQL uses, so that's
> also potentially confusing.

This is a related problem, we should have a terminology for contrib
tools such as pg_standby or pg_archivecleanup, for modules like the one
you talk about, that provide new features but nothing visible from SQL,
and extensions, that are all about SQL --- and if I can work on my plans
will get even more about SQL in a near future.

It's too late for me today to contribute nice ideas here though.

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