From: | Brook Milligan <brook(at)biology(dot)nmsu(dot)edu> |
---|---|
To: | peter_e(at)gmx(dot)net |
Cc: | pramsey(at)refractions(dot)net, dblasby(at)refractions(dot)net, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: [PATCHES] Re: PostGIS spatial extensions |
Date: | 2001-08-15 15:38:37 |
Message-ID: | 200108151538.JAA21191@biology.nmsu.edu |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-patches |
Projects that are as organized, professional, and value-adding as yours is
can surely stand on their own. I compare this to the recently released
OpenFTS. If we start including projects of this size we'd explode in size
and maintenance overhead.
Doesn't this discussion indicate that the time is fast approaching, if
not already past, for some type of system for handling installation of
3rd party software?
It would seem that two prerequisites would need to be satisfied to do
this:
- Definition and implementation of the interface to be provided for
extensions. Presumably, this would involve defining a well-designed
set of public header files and associated libraries at the right
level of granularity. For example, encapsulating each type in its
own header file with a standardized set of operations defined in a
server-side library would be extremely valuable. The library (or
libraries) could be used to link the backend and installed for
extensions to take advantage of preexisting types when others need
to construct new more complex ones.
- Definition and implementation of a consistent extension management
system for retrieving, compiling, and installing extensions. This
could even be used for installing the system itself, thereby making
the entire operation of managing the software consistent.
I point out that the NetBSD pkgsrc system[1] does the latter in an
extremely flexible and well-designed manner, and has been a major
foundation for the openpackages project. It even includes 7 distinct
packages[2] for different elements of PostgreSQL, not including a
number of other packages broken out for different interfaces. The
same system could be adopted for managing 3rd party extensions.
Having been involved in defining what header files to install, and
having been actively involved in developing new types for use in our
installation, I can say that external packaging of PostgreSQL, local
extension of PostgreSQL, and management of 3rd party software would be
greatly enhanced by an effort to address the two prerequisites
mentioned above.
Cheers,
Brook
---------------------------------------------------------------------------
[1] http://www.netbsd.org/Documentation/software/packages.html
[2] ftp://ftp.netbsd.org/pub/NetBSD/packages/pkgsrc/databases/README.html
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2001-08-15 15:42:29 | Re: Re: To be 7.1.3 or not to be 7.1.3? |
Previous Message | Karel Zak | 2001-08-15 15:37:31 | Re: encoding names |
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2001-08-15 16:09:37 | Re: PostGIS spatial extensions |
Previous Message | Denis Perchine | 2001-08-15 06:12:03 | Re: patch for JDBC PreparedStatement |