Обсуждение: 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