I can understand the ACS-core team's feelings that supporting multiple databases are a waste of time. However, you don't have to be in the "real world" long to realize that clients are not always rational or unbiased about how things should work and what tools to use. In other words, you don't always get to choose your own database and may loose contracts if you can't meet the client's requirements.
Even Phillip Greenspun himself has spoken of porting the ACS to *gag* WindowsNT and *retch* Microsoft SQL-server. And these would certainly be far more involved and labor-intensive than (as Don points out) modifications for different SQL dialects.
So one question that immediately springs to mind, is if Don's conjecture is true (that a database-agnostic system would not be of interest to aD, and they would be unlikely to fold such changes back into the source tree), then where does that leave us? When Ben suggested that ACS/pg might someday just be a feature-equivalent port of the ACS, rather than an architecturally-identical port I was somewhat shocked, but after learning more I wonder if this isn't perhaps the best option.
Perhaps I am just naive, but I really think it should be possible to migrate a website from one version of the ACS to another without having to hand-code every change. For example, at my current employer when we make a large change to a database construct that changes the way existing data should be stored, we have to write a "Rel" program (release program) that will walk through the database and update these values. These kinds of tasks should be possible without having to redo it for each and every site. However, I might not grasp the whole of the ACS's architecture (in fact I am sure I do not) and could be missing a key point.
