Slashdot Mirror
PostgreSQL 7.1 Released
Moosbert writes: "The latest and greatest PostgreSQL has been released. Major new features include write-ahead logging for better performance and reliability, outer joins, unlimited row size, and more complex queries (subselects in FROM, views with aggregates, etc.). Get yours from a mirror."
I think that samba is conciderd more Linux of linux software because it's anti-windows. PostgreSQL is usefull on windows, so it's just an upgrade.
I can't seem to find a changelog for this. There site seams damm slow. Anyone have a mirror of the changelog or release notes?
postgres has a number of very nice features, like stored functions and transactions.
Don't forget cursors. Since they require transactions I suppose you've included them though.
There's nothing nicer than being able to ask the database for a top ten list or otherwise get a subset of data from a large table without pulling the entire table into Perl. Combine that with the stored functions and you can do some very powerful things within the database... which is actually exactly what databases are so popular for.
Just about anyone can store things in a flat file and hash it to get fast search results. It's the ability to manipulate data that makes a database powerful, not just its raw speed on simple selects.
Is online backup. Shutting down and using pg_dump just doesn't rock muh world.
In every other respect though I love Postgres. It is a serious RDBMS and should have a spot in Open Source history right up there with Samba.
I don't know about you, but I try to keep by database as separated as possible from the application/business logic.
This is fine for some, maybe even most instances but when you are working on high performance and/or large applications it becomes necessary to more tightly integrate with the datastore and let the database do the hard work. Hell even letting the database do things like sorting and ordering (which does not rely on integration) output tends to be faster and more efficient of resources than pulling it into application-space and doing it there.
This is especially true with large tables when you only want a certain subset (top 10 selling items, top 50 support issues, etc. -- you don't pull in all 10000 (100k, 1M, whatever) rows into a Perl script or C program and strip off the ones you want; that's ludicrous. You ask the DB for what you want via cursors)
Sticking bunches of code in the database via stored procedures violates this; the result is my app is now tied to the database. That can be quite a pain to upgrade.
Moving from Postgres to Sybase or Oracle when stored procedures and other goodies are present is trickier, yes. But the performance you get with stored procedures not only allows you to forego the upgrade for (much) longer but also tends to out-and-out work better.
Why, then, is it seen as an advantage to perform application logic in the database?
As mentioned above: performance. Also more efficent use of resources (memory, cached storage, processor utilization, etc.) (e.g. the database already knows where things are, has them hashed, indexed and possibly (pre-)cached and ready for your app.
You don't want to put a lot of complex and "proprietary" (in the application sense -- things which aren't used to maintain database integrity or get results out faster) code in the stored procedure. You do, however, want to put complex selects, inserts and updates into the stored procedures and call them from application space as a higher-level command. Or have the database call them automatically to keep data integrity via triggers.
For what it's worth, I agree with you in keeping code to run the application the hell out of the database, but I do also see the value in integrating specific functions right into the database. It's a bit of a trade-off for upgradability but really if you're specifying a system you don't WANT to upgrade it for as long as possible and you'll quote hardware / software which will do the job right the first time around and with a certain amount of anticipated growth.
"...while they keep one-upping each other..."
um... as far as i know, the only advantage mysql has over postgres is speed. postgres has a number of very nice features, like stored functions and transactions.
it does seem as though mysql is catching up with the features. should be interesting to see if it can maintain the speed.
---
yes, i know. :)
---
There is some documentation work in progress on the topic here -> http://techdocs.postgresql.org/installguides.html# replicating
I don't know about you, but I try to keep by database as separated as possible from the application/business logic. The resultant 3-tiered design lets me change any portion of the app independently of the other. Most important, it lets me change the database to another that suits my needs with a minimum of effort. Sticking bunches of code in the database via stored procedures violates this; the result is my app is now tied to the database. That can be quite a pain to upgrade.
Why, then, is it seen as an advantage to perform application logic in the database?
You know that the email that quote came from was a april fool's joke, right? Unless you think Linux Torvalds really uses MS Outlook...
According to the /. icons, PostgreSQL is an upgrade while Samba is Linux-related. Hello?
I can't wait for the new religious wars to begin. MySQL vs. PostgreSQL. Who cares who comes out on top? I doubt either will come out on top. But while they keep one-upping each other and tweaking this and that and the other ad naseum, one of these days we'll stop and look around. Suddenly they won't be the Open Source "challengers." They'll be the default choice. And most of us probably won't see it happen. We'll only notice it after the fact.
The old guard will follow the road of most closed-source software: Specific niches for select clients.
So has anyone used it on Win32 lately? I've only ever played with PostgreSQL on Linux. I'm curious as to how well the ODBC libraries hold up.
- I don't need to go outside, my CRT tan'll do me just fine.
Yes, I've tried the 7.1 ODBC driver, and it works great. It's even been updated in the 7.1 source. (With minor tweaks.) That said, when I checked, (7.1 was still in beta, then) to build the Win32 ODBC driver, you still had to use MSVC, rather than Cygnus GCC. And the instructions for how to do that were not terribly well publicized. I'm sure the updated binaries of the driver will be available soon. (If not already.)
"The simplest solution is to ignore your dead children."
It's as simple as that - unless you have a really low performance computer.
Anything Mysql does, postgres can do. Or close to.
Postgres supports stuff that mysql doesn't support, or has JUST started to support.
The only real advantage to Mysql, is that you're allowed more freedom in changing existing tables. I must admit i get kinda annoyed when i have to redo yet another Postgresql table because it turned out I didn't need that column anyway.
Stop the brainwash
Yea, I'm using the odbc to log ms VSS checkins to SourceForge running a beta of 7.1.
Last time I checked the newest ODBC driver for Windows PostgreSQL clients was 6.5.
Worked with 7.0, though.
Anyone tried 'em with 7.1?
As per tradition, its a pain converting the binary data-on-disk files between versions.
um, no.