Slashdot Mirror

http://www.postgresql.org/about/licence it uses the fucking BSD license, it doesn't get anymore free.

http://www.postgresql.org/docs/faqs.FAQ.html#item1.1

"postgresql-8.0.2.tar.gz ... GNU General Public License (GPL)"

Wrong license. As mentioned on the PostgreSQL site page, the project uses the BSD license.

Judging from some of the activity here, that's probably not a serious question. But let's pretend it is. However, a lot of little Bill fans will get their feelings hurt.

Bill's toy bag is just that, a toy bag, that what little it does is on and for Windows -- only. And it's near a few decades late in coming. A comprehensive answer could go on for pages if you start to include various languages like Java, Python, Perl, C, and Ada. or Tomcat, Lenya, Swish, and many others staples. That's not even counting PHP and PHP-based kit, CPAN and others.

However the press release does not say what the MS "tools" do or, more correctly, claim to do. Students would be more employable playing WoW. For those that have been living in a cave for the last 15 years here's a recap of the main professional tools you will find in industry. There are others, but they're mostly open source, too, except a few big items like Oracle and DB2. None are MS.

IDEs

• Netbeans
• Eclipse
• Emacs - it's underrated
• Kdevelop - it's also underrated

Databases

• MySQL (now Sun)
• Postgresql

GUI toolkits

• Qt (now Nokia)
• GTK+
• wxWidgets

MS has held back computing far too long. The sooner it gets out of the way, the sooner both business and research can get back on track. Bill and his anti-American movement can go take a hike, there's no place for either MS or MS boosters in today's economy.

Let's pretend that's a serious question. Well, the press release does not say what the "tools" do. However, for those that have been living in a cave for the last 15 years here's a recap of the main professional tools you will find in industry. There are others, but they're open source, too, except a few big items like Oracle and DB2.

IDEs

• Netbeans
• Eclipse
• Emacs - it's underrated

Databases

• MySQL
• Postgresql

GUI toolkits

• Qt
• GTK+
• wxWidgets

The list could go on for pages if you start to include various languages like Java, Python, Perl, C, and Ada. or Tomcat, Lenya, Swish, and many others staples. That's not even counting PHP and PHP-based kit. Bill's toy bag is just that, a toy bag, that what little it does is on and for Windows. And it's near a few decades late in coming.

MS has held back computing far too long. The sooner it gets out of the way, the sooner both business and research can get back on track. Bill and his anti-American movement can go take a hike, there's no place for them.

It would seem not to. Yeah, I wish it had that, too. The other posters who keep telling you to get faster IO miss the idea of having extra CPUs handling locking, cache management, etc. so that even single running queries are faster.

Are you retarded, my dear sir? If you look at the link you posted, a bit above, you have table of what values you can fit in those datatypes. Not hard to figure out. Creating a cluster is not something obvious? No, I guess it isn't. Maybe you should go RTFM or use a distribution that does that for you.

As for unsigned integers and you not being able to figure it out... Please stick to MySQL, thank you.

Ok, so I've decided to give postgres a try. Took me a half hour just to figure out that I needed to create a cluster. So now I can actually connect to the postgres server. Ok, so I want to create my first table. What do you know, the postgres docs don't even give enough information on data types to be able to know what the different integer types are, and wtf are int2, int4, int8? You call 10 sentences on ints documentation?

You know why postgres isn't widely used? Because a newcomer can't even fcuking find out how to declare an unsigned int column, if they are even possible! The docs suck, and googling for tutorials doesn't turn up squat. No wonder I once installed mysql and postgres side-by-side, and had scrapped postgres within the first couple hours. Can't figure anything out.

This is one of those things that's painful only until you've crossed a certain threshold of information, then it never bothers you again. It's better now but still harder to put the pieces together than it should be.

Start with the documentation on creating a cluster: http://www.postgresql.org/docs/current/static/creating-cluster.html In 8.3 the default of using auth you mentioned has been removed, for the reasons you described. So it now runs as unsecured for local users by default and you have to worry about this yourself, which since it reduces the frustration at getting started was deemed an improvement.

That page suggests some options you can pass to initdb to adjust the default security level. Now you want to look at the initdb docs: http://www.postgresql.org/docs/current/static/app-initdb.html See that if you use -W/--pwprompt (same thing) you can assign a password to the database superuser at cluster creation time. If you do that, you can now change the default authentication scheme to password-based (-A md5 passed to initdb will do that), you'll be secure, and you'll have one user you can login as (postgres) to create more.

To see what other authentication methods are available and to learn what your options are look at http://www.postgresql.org/docs/current/static/client-authentication.html The one you really need to dive into is pg_hba.conf which is the magic text file to edit here. A new one of those will be put in the base directory of your new database cluster. Open that file up, look at the documentation, and you'll need to add a line to add network support like one those in the examples. Probably something like

host postgres all 192.168.12.0/24 md5

(allow access to anybody on the 192.168.12 subnet access the database with a password)

That should get you past the ugly initial hurdles. The next document you may need is how to add more users: http://www.postgresql.org/docs/current/static/sql-createrole.html

again look at the examples first and then backtrack to the parameters, will make more sense that way. After that you'll want to create more databases with createdb: http://www.postgresql.org/docs/current/static/app-createdb.html

And then you should be able to find your away around from there using the psql command line tool.

Note that once you get past accepting connections over the network, you could use a tool like pgAdmin III to handle the rest of this work using a slicker interface. There's even a copy of it bundled with the Windows installer you can use on such a client to administer a remote server running a real OS. It's of course possible to install pgAdmin manually on other platforms as well, see http://www.pgadmin.org/ for other verions (note that binary packages for platforms like RPM don't show up in every release, you have to go back to v1.8.0 to get the last full set of packages).

This is one of those things that's painful only until you've crossed a certain threshold of information, then it never bothers you again. It's better now but still harder to put the pieces together than it should be.

Start with the documentation on creating a cluster: http://www.postgresql.org/docs/current/static/creating-cluster.html In 8.3 the default of using auth you mentioned has been removed, for the reasons you described. So it now runs as unsecured for local users by default and you have to worry about this yourself, which since it reduces the frustration at getting started was deemed an improvement.

That page suggests some options you can pass to initdb to adjust the default security level. Now you want to look at the initdb docs: http://www.postgresql.org/docs/current/static/app-initdb.html See that if you use -W/--pwprompt (same thing) you can assign a password to the database superuser at cluster creation time. If you do that, you can now change the default authentication scheme to password-based (-A md5 passed to initdb will do that), you'll be secure, and you'll have one user you can login as (postgres) to create more.

To see what other authentication methods are available and to learn what your options are look at http://www.postgresql.org/docs/current/static/client-authentication.html The one you really need to dive into is pg_hba.conf which is the magic text file to edit here. A new one of those will be put in the base directory of your new database cluster. Open that file up, look at the documentation, and you'll need to add a line to add network support like one those in the examples. Probably something like

host postgres all 192.168.12.0/24 md5

(allow access to anybody on the 192.168.12 subnet access the database with a password)

That should get you past the ugly initial hurdles. The next document you may need is how to add more users: http://www.postgresql.org/docs/current/static/sql-createrole.html

again look at the examples first and then backtrack to the parameters, will make more sense that way. After that you'll want to create more databases with createdb: http://www.postgresql.org/docs/current/static/app-createdb.html

And then you should be able to find your away around from there using the psql command line tool.

Note that once you get past accepting connections over the network, you could use a tool like pgAdmin III to handle the rest of this work using a slicker interface. There's even a copy of it bundled with the Windows installer you can use on such a client to administer a remote server running a real OS. It's of course possible to install pgAdmin manually on other platforms as well, see http://www.pgadmin.org/ for other verions (note that binary packages for platforms like RPM don't show up in every release, you have to go back to v1.8.0 to get the last full set of packages).

This is one of those things that's painful only until you've crossed a certain threshold of information, then it never bothers you again. It's better now but still harder to put the pieces together than it should be.

Start with the documentation on creating a cluster: http://www.postgresql.org/docs/current/static/creating-cluster.html In 8.3 the default of using auth you mentioned has been removed, for the reasons you described. So it now runs as unsecured for local users by default and you have to worry about this yourself, which since it reduces the frustration at getting started was deemed an improvement.

That page suggests some options you can pass to initdb to adjust the default security level. Now you want to look at the initdb docs: http://www.postgresql.org/docs/current/static/app-initdb.html See that if you use -W/--pwprompt (same thing) you can assign a password to the database superuser at cluster creation time. If you do that, you can now change the default authentication scheme to password-based (-A md5 passed to initdb will do that), you'll be secure, and you'll have one user you can login as (postgres) to create more.

To see what other authentication methods are available and to learn what your options are look at http://www.postgresql.org/docs/current/static/client-authentication.html The one you really need to dive into is pg_hba.conf which is the magic text file to edit here. A new one of those will be put in the base directory of your new database cluster. Open that file up, look at the documentation, and you'll need to add a line to add network support like one those in the examples. Probably something like

host postgres all 192.168.12.0/24 md5

(allow access to anybody on the 192.168.12 subnet access the database with a password)

That should get you past the ugly initial hurdles. The next document you may need is how to add more users: http://www.postgresql.org/docs/current/static/sql-createrole.html

again look at the examples first and then backtrack to the parameters, will make more sense that way. After that you'll want to create more databases with createdb: http://www.postgresql.org/docs/current/static/app-createdb.html

And then you should be able to find your away around from there using the psql command line tool.

Note that once you get past accepting connections over the network, you could use a tool like pgAdmin III to handle the rest of this work using a slicker interface. There's even a copy of it bundled with the Windows installer you can use on such a client to administer a remote server running a real OS. It's of course possible to install pgAdmin manually on other platforms as well, see http://www.pgadmin.org/ for other verions (note that binary packages for platforms like RPM don't show up in every release, you have to go back to v1.8.0 to get the last full set of packages).

This is one of those things that's painful only until you've crossed a certain threshold of information, then it never bothers you again. It's better now but still harder to put the pieces together than it should be.

Start with the documentation on creating a cluster: http://www.postgresql.org/docs/current/static/creating-cluster.html In 8.3 the default of using auth you mentioned has been removed, for the reasons you described. So it now runs as unsecured for local users by default and you have to worry about this yourself, which since it reduces the frustration at getting started was deemed an improvement.

That page suggests some options you can pass to initdb to adjust the default security level. Now you want to look at the initdb docs: http://www.postgresql.org/docs/current/static/app-initdb.html See that if you use -W/--pwprompt (same thing) you can assign a password to the database superuser at cluster creation time. If you do that, you can now change the default authentication scheme to password-based (-A md5 passed to initdb will do that), you'll be secure, and you'll have one user you can login as (postgres) to create more.

To see what other authentication methods are available and to learn what your options are look at http://www.postgresql.org/docs/current/static/client-authentication.html The one you really need to dive into is pg_hba.conf which is the magic text file to edit here. A new one of those will be put in the base directory of your new database cluster. Open that file up, look at the documentation, and you'll need to add a line to add network support like one those in the examples. Probably something like

host postgres all 192.168.12.0/24 md5

(allow access to anybody on the 192.168.12 subnet access the database with a password)

That should get you past the ugly initial hurdles. The next document you may need is how to add more users: http://www.postgresql.org/docs/current/static/sql-createrole.html

again look at the examples first and then backtrack to the parameters, will make more sense that way. After that you'll want to create more databases with createdb: http://www.postgresql.org/docs/current/static/app-createdb.html

And then you should be able to find your away around from there using the psql command line tool.

Note that once you get past accepting connections over the network, you could use a tool like pgAdmin III to handle the rest of this work using a slicker interface. There's even a copy of it bundled with the Windows installer you can use on such a client to administer a remote server running a real OS. It's of course possible to install pgAdmin manually on other platforms as well, see http://www.pgadmin.org/ for other verions (note that binary packages for platforms like RPM don't show up in every release, you have to go back to v1.8.0 to get the last full set of packages).

This is one of those things that's painful only until you've crossed a certain threshold of information, then it never bothers you again. It's better now but still harder to put the pieces together than it should be.

Start with the documentation on creating a cluster: http://www.postgresql.org/docs/current/static/creating-cluster.html In 8.3 the default of using auth you mentioned has been removed, for the reasons you described. So it now runs as unsecured for local users by default and you have to worry about this yourself, which since it reduces the frustration at getting started was deemed an improvement.

That page suggests some options you can pass to initdb to adjust the default security level. Now you want to look at the initdb docs: http://www.postgresql.org/docs/current/static/app-initdb.html See that if you use -W/--pwprompt (same thing) you can assign a password to the database superuser at cluster creation time. If you do that, you can now change the default authentication scheme to password-based (-A md5 passed to initdb will do that), you'll be secure, and you'll have one user you can login as (postgres) to create more.

To see what other authentication methods are available and to learn what your options are look at http://www.postgresql.org/docs/current/static/client-authentication.html The one you really need to dive into is pg_hba.conf which is the magic text file to edit here. A new one of those will be put in the base directory of your new database cluster. Open that file up, look at the documentation, and you'll need to add a line to add network support like one those in the examples. Probably something like

host postgres all 192.168.12.0/24 md5

(allow access to anybody on the 192.168.12 subnet access the database with a password)

That should get you past the ugly initial hurdles. The next document you may need is how to add more users: http://www.postgresql.org/docs/current/static/sql-createrole.html

again look at the examples first and then backtrack to the parameters, will make more sense that way. After that you'll want to create more databases with createdb: http://www.postgresql.org/docs/current/static/app-createdb.html

And then you should be able to find your away around from there using the psql command line tool.

Note that once you get past accepting connections over the network, you could use a tool like pgAdmin III to handle the rest of this work using a slicker interface. There's even a copy of it bundled with the Windows installer you can use on such a client to administer a remote server running a real OS. It's of course possible to install pgAdmin manually on other platforms as well, see http://www.pgadmin.org/ for other verions (note that binary packages for platforms like RPM don't show up in every release, you have to go back to v1.8.0 to get the last full set of packages).

I think the disconnect is that PostgreSQL has a different definition of schema than you are using.

I guess my initial point was that management-types look only at the glossy for a product. When you look at Postgres' feature matrix you don't see replication anywhere on it. Compare that to Oracle's offerings (Industrial-strength replication built-in! Call us now!)... well, you get the gist.

As such, the question then becomes: when am I going to be certain that the data is written to disk?

When a well-defined delay expires, see wal_writer_delay. The maximum window of vulnerability is 3 times the WAL writer delay.

See more here:
http://www.postgresql.org/docs/8.3/static/wal-async-commit.html

As such, the question then becomes: when am I going to be certain that the data is written to disk?

When a well-defined delay expires, see wal_writer_delay. The maximum window of vulnerability is 3 times the WAL writer delay.

See more here:
http://www.postgresql.org/docs/8.3/static/wal-async-commit.html

Here's a feature matrix of new features vs. old versions. It's easy to see that 8.3 is a huge upgrade.

http://www.postgresql.org/about/featurematrix

Use dblink:
http://www.postgresql.org/docs/faqs.FAQ.html#item4.17

Not as slick as doing it entirely in SQL, but it works.

There are several ways to do cross-database JOINs in Postgres including dblink, and even to other DBMSs via dblink-tds and DBI-Link, but try schemas first, as another poster mentioned.

einhverfr (238914):
Being RIGHT is more importan than being fast.

Thank goodness PostgreSQL is both.

8.3 is just around the corner, so if anyone has still not checked it, please, do yourself a favor and read up on what's new, you'll be pleased.

• Release notes).
• Documentation.

einhverfr (238914):
Being RIGHT is more importan than being fast.

Thank goodness PostgreSQL is both.

8.3 is just around the corner, so if anyone has still not checked it, please, do yourself a favor and read up on what's new, you'll be pleased.

• Release notes).
• Documentation.

Postgres is BSD licenced. - http://www.postgresql.org/about/licence

Well, this could be something to breath life into MySQL which seemed to be in dire straits recently. After Oracle's low blows removed both of transactional engines, it looks like everyone is abandoning MySQL for Postgres.

There was no doubt what Oracle did was predatory, but if MySQL didn't use commercial InnoBase component they would not have had any issues.

Lets hope many contributors and users dump MySQL and go to PostgreSQL. I have used PostgreSQL, MySQL, and Oracle. I often thought PostgreSQL was underrated and suspect those switching will be happy.

I've found regex queries can run faster than string matching using LIKE. I don't know whether regex queries make better use of indexes, though. I recall reading something about LIKE not being able to take advantage of indexes, but that was some time (and a few versions) ago.

Anyways, try SELECT * FROM table WHERE title ~* '.*string.*' instead.

Take a look at http://www.postgresql.org/docs/8.2/static/functions-matching.html for more details on pattern matching.

Security is about how things are done not how they turn out to be. This means you use placeholders such that then the database layer doesn't have to parse the data. If the database driver is stupid such that placeholders are just cosmetic, then well, no security gained.

If you don't use placeholders on ASCII text files, easy to sanitize anyway. But if you don't use placeholders on multi-byte encoded characters, then it is SQL injection and a security hole.

http://www.postgresql.org/docs/techdocs.50

PostgreSQL was hit by the problem. The problem was later identified in MySQL and other databases as well. Escaping only works properly in regular ASCII, but still a pain for the parser. Data may be passed to the server faster and securely with prepared statements.

If it requires the presence of GNU Readline, it's in violation of section 2 of the GPLv2, then.

However, looking in the manual, it can be compiled without GNU Readline or use NetBSD's libedit, so it's probably safe.

I recently finished a long comparison of PostgreSQL and MySQL in the context of mission-critical data that gives a lot more detail on the issues you bring up here.

The only async apis they have are like the example I gave before. These are sub-optimal!

It will make a MASSIVE difference in CPU/RAM usage...

And async is certainly not much more difficult - it's a new way of thinking, sure, something new to learn. But it's not really that difficult!

No, this is not something relevant to "the entire FOSS" community. For instance, if SCO had had more success, and this had adversely affected Linux (e.g. The Kernel), this would have generally led to migrations to the various BSD-based systems.

And adoption is, of course, a two-edged sword for those already in such communities; to some degree, the popularity of Linux draws in "bozos" that the BSD folk would rather not have around. There are remappings of the following that are possible :-). "Huh? Windows was designed to keep the idiots away from Unix so we could hack in peace. Let's not break that." -- Tom Christiansen

I'm more involved, these days, with the PostgreSQL community; the SCO lawsuits were fairly much irrelevant to that community, from some standpoints.

The best option for asynchronous PostgreSQL replication is Slony-I. It's extremely flexible and so far has proven to work very well. The devs supporting it are also very good. I do admit that there is a bit of a learning curve to get it configured and running, but this is something they are working on for the next major revision.

If you need to cluster PostgreSQL, have a look at pgpool and pgpool-II.

The best option for asynchronous PostgreSQL replication is Slony-I. It's extremely flexible and so far has proven to work very well. The devs supporting it are also very good. I do admit that there is a bit of a learning curve to get it configured and running, but this is something they are working on for the next major revision.

If you need to cluster PostgreSQL, have a look at pgpool and pgpool-II.

The datatypes themselves are utterly trivial. The hard part, if you
want them to be part of the numeric hierarchy, is figuring out what the
type promotion and implicit casting rules ought to be.

You can be happy now. From:
http://archives.postgresql.org/pgsql-committers/20 07-03/msg00136.php

Log Message:
-----------
Make use of plancache module for SPI plans. In particular, since plpgsql
uses SPI plans, this finally fixes the ancient gotcha that you can't
drop and recreate a temp table used by a plpgsql function.

I'd much rather prefer:

SGPJ - Solaris, Glassfish, PostgreSQL, Java

Wow, you can use .Net code in the database? While it's a welcome feature, most other databases have supported other languages for stored procedures for a while, and a lot more than just extra. For instance, check out this excerpt from the PostgreSQL website. Makes SQL servers capabilities a bit of a joke. PostgreSQL runs stored procedures in more than a dozen programming languages, including Java, Perl, Python, Ruby, Tcl, C/C++, and its own PL/pgSQL, which is similar to Oracle's PL/SQL. Included with its standard function library are hundreds of built-in functions that range from basic math and string operations to cryptography and Oracle compatibility. Triggers and stored procedures can be written in C and loaded into the database as a library, allowing great flexibility in extending its capabilities. Similarly, PostgreSQL includes a framework that allows developers to define and create their own custom data types along with supporting functions and operators that define their behavior. As a result, a host of advanced data types have been created that range from geometric and spatial primitives to network addresses to even ISBN/ISSN (International Standard Book Number/International Standard Serial Number) data types, all of which can be optionally added to the system.

Neither. I gave up 4 hours after installing, realising postgres has no documentation worth mention.

That and from what I've seen, I'd rather not be associated with its userbase.

Well, Postgres has support for Perl or Python or Ruby or Java, or in their pgSQL language for user-defined functions.. that's a huge plus compared to writing in C for simple things. http://www.postgresql.org/docs/8.1/static/plperl.h tml How's that for ugly? ;)

8.1 automatically does table maintenance (vacuum, stats, etc.)
http://www.postgresql.org/docs/8.2/static/routine- vacuuming.html#AUTOVACUUM

You can tune it as to when to do such operations, or what max percent of normal I/O can be used for those tasks.

'Do the popular free software implementations of SQL (MySQL, PostgreSQL, Firebird SQL, etc.) implement stored procedures in any sort of standard manner?'

I don't know what you mean by standard manner. According to this PostgreSQL uses something called procedural languages. But then again since when was SQL ever implimented in a common standard. Remember when Microsoft 'extended' SQL so as to allow spaces in table names, you only have to wrap the name in square brackets [] or back-ticks ``.

But my point is still valid, there must be any number of ways to achieve the same usability as sending an SQL query to the client, which fills in the variables and sends it back to the server. So that things like the below don't happen where you your replace the $ENV variable with a bogus SQL query.

SELECT fieldlist
FROM table
WHERE field = '$ENV';

If you just make sure you always use prepared SQL statements with positional arguments, you will never have any problems with SQL injection.

Actually, that is not true, as it ignores one problem: bugs in the database drivers. Seriously, there have been bugs in database drivers that have enabled SQL injection... I specifically remember a bug in the PostgreSQL JDBC driver a while back.

I also remember seeing a JDBC driver that simply inserted arguments into the string containing the SQL statement, although I fail to remember exactly which driver that was. This was a while back, mind you, so hopefully errors like that have been fixed. :)

Until I encountered these things, I believed that positional arguments was the silver bullet. The point here is that positional arguements in itself is no guarantee, it is only a part of an API. At some point you have to trust the developers of the database driver and the database itself, of course...

While it doesn't address standard SQL structures, I find most of the PostgreSQL specific information I need on the free cheat sheet at http://www.alberton.info/postgresql_cheat_sheet.ht ml

The main things missing are generate_series, current_setting, and set_config. There are also several new system information functions in PostgreSQL 8.2; see the documentation at http://www.postgresql.org/docs/8.2/static/function s-info.html for a list.

> Can someone point me at a single Open sourced project that offers the same,
> or at least equivalent, service as the closed source version?

OpenGroupware.Org - http://www.opengroupware.org/
PostgreSQL - http://www.postgresql.org/

BigMan, If you're coming from SQL Server, you'd be better off downloading and using Postgres 8.2.4 for windows, from here. PG is BSD licensed, which means you can bundle it with your commercial .NET-based apps for free.

The management interface for PG is on-par with SQL Server Studio; I use both on a daily basis. It's also "20 minutes to set up and start populating data". As an added plus, Postgres has all of the "standard" syntax and referential data integrity turned on out of the box.

You use MySQL if: a) you're developing a LAMP app for an inexpensive webhost that only allows MySQL databases, or b) all of your developers cut their teeth on MySQL and therefore productivity will drop if you ask them to use standard compliant syntax, or c) You're using an app (like SugarCRM or WordPress), the developers of which insisted on using funky MySQL-only features (instead of standard portable syntax) and therefore it's too much work to port to a standard syntax.

In all other cases, you use Postgres or some other commercial database. Postgres scales much better than InnoDB on any combination of a) larger numbers of read-write transactions, b) larger numbers of connections, c) more processors, d) larger datasets (including and beyond 400-500GB).

Cheers, -J

Check again: http://www.postgresql.org/docs/8.1/interactive/ddl -partitioning.html

Here are a few other examples of free programs which I forgot to include. Like the others they are available in both Windows and Linux versions.

• GnuPG - The GNU Privacy Guard which can encrypt and sign you data and your communications
• DOSBox the Dos emulator for running many old DOS games and programs
• Firebird the relational database program
• PostgreSQL object-relational database management system
• Stellarium is a free open source planetarium

For the last ten years, I've been developing Taskjitsu, an open source professional services automation system that tracks time sheets and tasks. It is freely available, GPL-licensed, and commercially supported by PKR Internet.

Taskjitsu is at its core a Java web application, layered on top of Tomcat and PostgreSQL. It runs on Windows, Linux, and any other system that can run Java 1.4. We have RPMs available that work with Red Hat Application Server 1.0 and other JPackage 1.6-derived systems.

For the IP part, postgresql has network operators and functions that can come in very useful.

http://www.postgresql.org/docs/current/static/func tions-net.html

So in theory you could have a script for "A" and "B" to automatically free up and find blocks.
And a script for "C" to actually allocate a manually decided block and set up the delegation etc.

Doesn't actually seem too hard if you start with a decent database schema, and are using sane DNS software ;).

Of course there are super expensive off the shelf solutions to do all sorts of stuff, but funny thing is you'd probably have to spend about the same amount of time and effort integrating them with your DNS, routers etc.

Exhibit A