Slashdot Mirror
PostgreSQL 8.0 Released
Christopher Cashell writes "The PostgreSQL project has released version 8.0 of their well known Object-Relational Database. New features include: Win32 Native Server, Savepoints, Point-In-Time Recovery, Tablespaces, and lots more. Downloads are available via bittorrent for Unix/Linux, and the much anticipated Win32 version, or via ftp (use a mirror!)." (Here's the official announcement.)
Now all I need is a magical installer which will convert my existing 7.2.4 systems to 8.x without missing a single beat or disrupting the existing programs written against the old libs.... I'm serious!
Converting 200Gb of data is not something you want to try do without downtime.
All that said, it's good to see PostgreSQL always improving. Good one guys.
One of the most exciting features of 8.0 is plperl, their Perl-based server side language
I'm not convinced. SQL is supposed to a standard, so you can move from one database server to another with not much effort. This is a big step away from that. Much like the features you'd find in Oracle or MS SQL.
My Karma: ran over your Dogma
StrawberryFrog
I didn't know the goal of Postgresql was to rid the world of windows.
It may, but it really helps for folks who use Windows and want to run a local copy of their database for development purposes.
Myself, I'm absolutely thrilled wiht this new release (and indeed, their new website -- the old one did look a bit naff). I expect PostGreSQL's popularity to increase a fair bit this year, and good luck to them!
LAPP, maybe, but certainly not WAPP.
Linux + Apache2 + PostgreSQL + Python == kickass webserver
I support the Center for Consumer Freedom
The dirty secret is that Postgres is actually easier to install and administer than mysql. I don't want to get into a religious argument with mysql users but ... oh hell yes I do.
I have worked with self-educated programmers who did not know how to do simple table joins or even modestly complex SQL queries or transactions, because they had learned what they thought was SQL by using Mysql. There is a whole generation of developers who now think that transactions aren't really necessary in a database application.
Postgres is really an Oracle killer at this point, and I know, having used Oracle. There is quite simply no reason to use any other relational database at this point, especially to back a live web site.
Some people say that providing open source applications on Windows helps proprietary software and the Windows monopoly, but I don't think so. Software like Apache, PHP, PostgreSQL on the server, and Mozilla Firefox, Thunderbird, and OpenOffice on the client lets Windows users gradually move over to open source applications. I think that's a much better way of getting people to switch than to ask them to do an all-or-nothing switch.
Don't they know that MySQL is the one to use for web backends? :)
Saying MySQL is better than Access is not saying much. MySQL may be excellent when it meets the requirements, but there are a lot of cases where it simply does not.
#!/
For lite uses, and many heavy ones, SQLite seems excellent. I haven't used it yet, but whoever writes for the project is an excellent communicator.
In my experience, most open source projects, and almost all commercial products, have a (maybe mostly unconscious) plan: "We will carefully measure how much hassle people will accept, and make sure we don't document anything more than enough to just barely keep people from rejecting us."
It's common to visit an open source project and find that, yes, they have a new version, but the manual is two years old. There are plenty of commericial projects that are the same way, like Netgear's FVS318. Their reference manual is for version 1.4, but the latest version is 2.4.
An advantage of open source projects is that they are usually far more honest than commercial projects. I love this from the PostgreSQL What's New page: "Although tested throughout our release cycle, the Windows port does not have the benefit of years of use in production environments that PostgreSQL has on Unix platforms and therefore should be treated with the same level of caution as you would a new product." Marketing people are generally so dishonest that they would not allow an honest statement like this.
MySQL is a non-standard implementation of SQL. That's a problem that's probably partly caused by not doing good documentation. If they had documented everything as they wrote MySQL, they might have seen what a mess they were making. Bad documentation obscures programming messes.
PostgreSQL has an elaborate documentation system, and the new features are very impressive.
Oracle will always have more features than any other given database product you care to compare it to, and there will always be those who find some of those Oracle-unique features irresistable. That's what it means to be the central product of a very large, wealthy and reasonably effective software company.
It is not a very meaningful comparison, though. Oracle also has a lot of stuff that nobody would be happy to see tacked on to PostgreSQL. Oracle is notoriously difficult to administer. The download of Oracle's database product is probably 500 times larger than PostgreSQL. (and 20 times larger than Oracle itself was just a few versions ago, which is interesting, and yes I'm guesstimating but still...)
In short, PostgreSQL doesn't need all the features of the Oracle db to be successful, as *nix and NT did not need all the features of a mainframe OS to be successful.
Now before I get modded down, I be to remind whoever might read this that what I am saying is FACT. - bogaboga
Unfortunately, many (quite a large percentage) of applications running MySQL *do* need MySQL features that don't exist in SQLite. Full text indexing, for one, which is utilized by many Forum web app.
I also suspect the master data is stored in a different place (either in another MySQL machine or other DB). So the MySQL machines that serve finance.yahoo.com are basically for read-only simple queries (but involve lots of rows). MySQL is perfect for this.
And the data is not really mission-critical. It's just a bunch of numbers (exchange rates, stock prices) aggregated from various places. Database crash? Just repopulate by querying the various data sources.
How would you recommend doing it, and still supporting Reat Uncommitted, Read Committed, Repeatable Read, and Serializable Transaction Isolation Levels (part of SQL 1992) then.
Consider this scenario.
- Connection A starts a transaction.
- Connection A does a count(*) -- expect the original number or f rows.
- Connection B starts a transaction.
- Connection B inserts a number of rows into your table.
- Connection A does a count(*) -- shouldn't see B's inserts
- Connection B does a count(*) -- should see B's inserts.
- Connection B commits
- Connection A does a count(*) -- still shouldn't see B's inserts for some transaction isolation levels.
With your magic RDBMS, what would you do? If you say lock tables during these operations your DB won't scale.