Re: [PATCHES] Re: PostGIS spatial extensions

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

In response to

Responses

Browse pgsql-hackers by date

  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

Browse pgsql-patches by date

  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