The idea that came up in the -hackers and -advocacy lists, and I think
it should be brought up as a separate thread, in -general.
Backgroud
Once in a while someone comes and suggests adding some package to
postgresql-contrib. Some other person asks for some feature and is directed
at Pgfoundry. Yet again, someone submits a package and is usually directed
to Pgfoundry to put it there.
While it is a great place to keep development there, but not so obvious a place
for random administrator/DBA/programmer... So the idea is to make something
akin to:
Comrehensive PostgreSQL Archive Network, or CPgAN
I would like to provoke a discussion how should such a thing look like,
and hopefully to make one.
First, I think it should be pretty intergrated into PostgreSQL, and should
by distribution agnostic. From user perspective it should be similar to
createuser, createdb, createlang commands. ie. user would call a shell
command, say:
pg_package dbname install name_of_package
and it would connect with cpgan, get list of packages, get sources,
compile sources (if C-backed), maintain dependencies, etc. Or at
least it should.
It's better to talk with an example. Let's assume the issn/isbn datatype
would be handled by that infrastructure.
If DBA would want to install it from source, she would use this pg_package
(or whatever the name) utility to download it, unpack, compile and install
generated lib...so file. It would also install, in some common place a sql
script which would install and uninstall the package. DBA should be able
to specify if package is available to all users or not (grant its usage), but
it is not essential right now. Command should be able to handle binary
packages well. Think: Linux distributions etc -- they would put all files
in place, then call pg_package to "notify" PostgreSQL about new additon.
The second part is "enabling" the usage within given database. A simple
running of bunch "CREATE" commands on given database. Plus a matching
deinstall script.
This raises couple of questions:
1. CREATE PACKAGE -- maybe its time to rethink such a command. :)
2. Where to store state information. A natural place would be a database
itself. A dedicated cpgan db with all dependencies? A bit fragile solution,
and much of managament will become cross-database (to install "PL/R"
to template1 db you would need to connect both to cpgan and template1,
but it may work.
3. There would be a need to automate the server side as possible. User
should be able to use it to search for package she desires. And developers
should be able to efficiently upload packages.
4. A "tree" of packages, PgFoundry's is too general I think. For instance
I feel that PgAdmin and other DB Administration projects would not belong
here, as they are rather interfaces to than extensions of. :) Say, a tree
with such a look:
pl/
pl/plr
pl/plperlng
replication/slony
datatype/uri
datatype/email
index/ltree
...of course its not complete and not ideal. I wnat to know how would
you organise such a tree.
5. A common documentation format. It would be great to be able to automatically
"merge in" documentation of extensions into PostgreSQL's Manual as a separate
Appendix. Right now its somewhere between Use The Source, Luke, README
files and what-author-provided documentation format.
What would this all give us? It would encourage development of simple
extensions,
and would greatly increase the ease of extending PostgreSQL by newbies. In the
long run it would bring more developers, as PostgreSQL would be perceived not
only as a "SQL DB" but also as a development platform, extensible and powerful.
What do you think?
Regards,
Dawid
