Horton

Re: Core Extensions relocation

Josh Berkus <josh@agliodbs.com>

View thread
From: Josh Berkus <josh@agliodbs.com>
To: pgsql-hackers@postgresql.org
Date: 2011-11-15T00:56:05Z
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

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

These should, in my opinion, all be Core Extensions.  I'd go further to
say that if something is materially an extension (as opposed to a tool
or a code example), and we're shipping it with the core distribution, it
either ought to be a core extension, or it should be kicked out to PGXN.

Am I completely misunderstanding what you're trying to accomplish here?

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

-- 
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com