Additional supplied modules
I've been thinking about the terminology used for various tools and
extensions in PostgreSQL. The documentation bundles all them together
in "Additional Supplied Modules, but really some are tools, some are
libraries and some are extensions:
Tools:
oid2name
pg_archivecleanup
pgbench
pg_standby
pg_test_fsync
pg_upgrade
vacuumlo
Libraries:
auth_delay
auto_explain
dummy_seclabel
passwordcheck
sepgsql
Extensions:
adminpack
btree_gin
btree_gist
chkpass
citext
cube
dblink
dict_int
dict_xsyn
earthdistance
file_fdw
fuzzystrmatch
hstore
intagg
intarray
isn
lo
ltree
pageinspect
pg_buffercache
pgcrypto
pg_freespacemap
pgrowlocks
pg_stat_statements
pgstattuple
pg_trgm
seg
sslinfo
tablefunc
test_parser
tsearch2
unaccent
uuid-ossp
xml2
Extension Packages:
spi (contains extensions timetravel, autoinc, insert_username, moddatetime)
In fact if someone has been told to install one of those extensions in
the SPI package, they might not know that it contains separate
extensions, so calling CREATE EXTENSION spi; will do nothing.
On top of this, tools will just exist and can be used without any
configuration, whereas libraries will need to be loaded either with
LOAD or in shared_preload_libraries, and extensions require CREATE
EXTENSION.
It seems very messy for all these to be bundled into the same section
as if they were all equals. And the completely random nature of the
naming conventions doesn't help either. (e.g. pg_stat_statements vs
pgstattuple).
Could we somehow categorise these, and also do something to clarify
that SPI is a collection of extensions rather than an extension
itself?
--
Thom Brown
Twitter: @darkixion
IRC (freenode): dark_ixion
Registered Linux user: #516935
EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
On 10/13/11 6:32 AM, Thom Brown wrote:
Could we somehow categorise these, and also do something to clarify
that SPI is a collection of extensions rather than an extension
itself?
Alternately we should clean up SPI and break it out into its separate
extensions.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
Josh Berkus <josh@agliodbs.com> writes:
On 10/13/11 6:32 AM, Thom Brown wrote:
Could we somehow categorise these, and also do something to clarify
that SPI is a collection of extensions rather than an extension
itself?Alternately we should clean up SPI and break it out into its separate
extensions.
Additionaly we need to pick some and bless them as in-core extensions
(installed by default, you still need to CREATE EXTENSION to benefit
from them) and move the others into either an "example" section or an
"additional" section where production ready goodies are to be found but
just were not selected as in-core extensions for whatever reasons
(export laws in the case of pgcrypto, some non portable dependencies for
other choices, etc).
We might even have some more categories into, such as "debug",
"profile", "data type", "compat" and all. Maybe a new field with that
kind of classification in the control file would be good (it would be
found in the catalogs too).
Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
On 13 October 2011 19:46, Dimitri Fontaine <dimitri@2ndquadrant.fr> wrote:
Josh Berkus <josh@agliodbs.com> writes:
On 10/13/11 6:32 AM, Thom Brown wrote:
Could we somehow categorise these, and also do something to clarify
that SPI is a collection of extensions rather than an extension
itself?Alternately we should clean up SPI and break it out into its separate
extensions.Additionaly we need to pick some and bless them as in-core extensions
(installed by default, you still need to CREATE EXTENSION to benefit
from them) and move the others into either an "example" section or an
"additional" section where production ready goodies are to be found but
just were not selected as in-core extensions for whatever reasons
(export laws in the case of pgcrypto, some non portable dependencies for
other choices, etc).We might even have some more categories into, such as "debug",
"profile", "data type", "compat" and all. Maybe a new field with that
kind of classification in the control file would be good (it would be
found in the catalogs too).
An extra bit of confusion comes with installing languages as
extensions. These aren't considered to be one of the additional
supplied modules, so not all items which require installing via CREATE
EXTENSION are shown alongside others. And the CREATE EXTENSION page
doesn't mention function languages at all.
--
Thom Brown
Twitter: @darkixion
IRC (freenode): dark_ixion
Registered Linux user: #516935
EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
Josh Berkus <josh@agliodbs.com> writes:
On 10/13/11 6:32 AM, Thom Brown wrote:
Could we somehow categorise these, and also do something to clarify
that SPI is a collection of extensions rather than an extension
itself?
Alternately we should clean up SPI and break it out into its separate
extensions.
I don't feel a need to do that in the source tree, but maybe flattening
the documentation would be worthwhile.
regards, tom lane