dev-db/postgresql-server 8.4.4 & 8.4.5 (as well as any other postgres-server ebuild most likely) comes with bundled sets of scripts/sql files that expand functionality based on (pre)installed libraries/packages, however they are not linked to any USE keywords and require manual activation by means of postgress. It would be well within realm of possibilities (and in my opinion fits Gentoo concepts quite nicely) if the ebuild would provide list of keywords which would activate corresponding scripts at post-install stage. Reproducible: Always Steps to Reproduce: For example, in order to provide hashing/ciphering facilities necessary for SHA1, DES, MD5,.. etc. routine - one needs to acquire libopenssl (? to be confirmed) and perform: sudo -u postgres psql *template/database* < /usr/share/postgresql-8.4/contrib/pgcrypto.sql ... for each existing database and template if done postfactum. All scripts/sql file necessary for adding or removing such functionality come with ebuild now but are not being used. A USE flag (i.e. "crypto") could be linked to such script and, if supplied by user, would invoke these actions at post-install/configure time.
To answer your question about crypto first: crypto does not require OpenSSL. crypto can, however, take advantage of the encryption mechanisms in OpenSSL. The following link details which encryption mechanisms are built-in and which ones become available with OpenSSL, which of the methods you listed only DES isn't built-in: http://www.postgresql.org/docs/9.0/static/pgcrypto.html#PGCRYPTO-WITH-WITHOUT-OPENSSL There are several items that keep your proposal from being feasible. Calls to psql in pkg_postinst() may or may not fail depending on whether the database cluster has been initialized. Furthermore, they may or may not fail depending on whether or not the server is running. And they may or may not fail depending on whether or not a password is required, local availability, or even localhost or remote. It could be called in pkg_config() after initdb finishes its processes, but it would be promptly overwritten as soon as the user/administrator does a pg_dump/pg_restore/pg_upgrade if there are colliding functions. And, let's not forget that the server would have to be started without the administrator first modifying pg_hba.conf. Third, if the administrator modified those functions provided by the modules, those modifications would be lost on subsequent minor updates. So, no, they won't be implemented in the ebuild. But, there is a possibility of easing contrib module management outside of the ebuilds. Bash is not exactly up to the task of working with contrib modules, but I could write a Perl program that could manage such things. So, this is something that I am now considering. It won't come anytime real soon, so in the meantime I will add some einfo statements directing people to the appropriate documentation for contrib modules.
After much thought and consideration and with recent changes to how PostgreSQL handles extensions, I will not be adding anything to the PostgreSQ-ebuild ecosystem to handle this request.
