Horton

Re: Core Extensions relocation

Thom Brown <thom@linux.com>

View thread
From: Thom Brown <thom@linux.com>
To: Josh Berkus <josh@agliodbs.com>
Cc: pgsql-hackers@postgresql.org
Date: 2011-11-15T01:14:08Z
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 →

  1. Updates to contrib/isn ISBN tables.

  2. Add a "LIKE = typename" clause to CREATE TYPE for base types. This allows

On 15 November 2011 00:56, Josh Berkus <josh@agliodbs.com> wrote:
> Greg,
>
> So I'm a bit unclear on why most of the optional data types were
> excluded from your list of Core Extensions.  I would regard the
> following as stable and of general utility:
>
> btree_gin
> btree_gist
> citext
> dblink
> file_fdw
> fuzzystrmatch
> hstore
> intarray
> isn
> ltree
> pgcrypto
> pg_trgm
> unaccent
> uuid-ossp

Greg clarified on the core extensions page text:

"These core extensions supply useful features in areas such as
database diagnostics and performance monitoring."

None of those others perform such a role.  Instead they add additional
functionality intended to be utilised as part of general data usage,
adding new types, operators, query functions etc.  Maybe the term
"core" is inappropriate.  Instead we might wish to refer to them as
"utility extensions" or something like that, although that may be just
as vague.

> ... also, why is there still a "tsearch2" contrib module around at all?

Backwards compatibility.  No-one will use it except if they're coming
from an older version.

-- 
Thom Brown
Twitter: @darkixion
IRC (freenode): dark_ixion
Registered Linux user: #516935

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company