PostgreSQL 9.0 Released 344
poet writes "Today the PostgreSQL Global Development Group released PostgreSQL 9.0. This release marks a major milestone in the PostgreSQL ecosystem, with added features such as streaming replication (including DDL), Hot Standby and other nifty items like DO. The release notes list all the new features, and the guide explains them in greater detail. You can download a copy now."
Thank you! (Score:5, Insightful)
Re:"Great leap forward" (Score:5, Insightful)
Re:Has the Documentation Been Improved? (Score:2, Insightful)
If you have actually read the documentation, you would find that it is one of the finest pieces of software documentation out there. If one could have any complaint it could be that there is just so much of it.
Re:Firebird is better (Score:3, Insightful)
Please tell me you're kidding. Anyone suggesting MySql for real work should just be laughed at.
Re:Waiting for a capable PostgreSQL front-end (Score:3, Insightful)
Access is too easy. It lets people who have no idea what they are doing make a half working solution that then has to be replaced with real code and a real DB.
Re:Waiting for a capable PostgreSQL front-end (Score:2, Insightful)
Better that it be Access rather than FileMaker Pro. There is an upgrade path of sorts from Access to SQL Server. So if you have one of those unfortunate cases where it was mandated that a dinky workgroup app be shoved out enterprise wide then at least there are options to move the data and app logic to platforms that can take the load. I'm not saying that it's easy but someone who knows what they are doing can get started on fixing it pretty quickly.
That situation with Filemaker Pro is much uglier and Filemaker Pro does even more to encourage marginal developers. FM Pro is an unholy glop of database, scripting language, and a widget set. Trouble with any of those domains tends to impact the other two. And one commercial FM Pro app I was saddled with would corrupt data when too many users hit the server at once. "Too many" being around 12 users. The other cute thing about that app was every person who used it had to have FM Pro client installed on the machine. The developer was a reseller for FileMaker too. Maybe THAT is why he didn't create a standalone runtime that could connect to the server. I'm happy to say that nasty thing is mostly phased out now.
Re:Firebird is better (Score:3, Insightful)
"Real Work"? What's that? MySQL was for a very long time the DB used by adsense and youtube...
How many projects use MySQL and how many use PostgreSQL?
PostgreSQL might be a good db, but that doesn't make MySQL a piece of shit...
Re:Cool (Score:3, Insightful)
A good optimizer could easily partition a traditional trigger into internal triggers that only ran when certain columns were updated, and in most cases maintenance would be much simpler.
Re:Has the Documentation Been Improved? (Score:3, Insightful)
Dear lord, this many replies, and only one person has the decency to supply a link?
Kudos to you sir.
Most likely because we all assume you can get off your ass and visit the site where the Documentation link is readily visible to the naked eye.
Re:Has the Documentation Been Improved? (Score:3, Insightful)
Re:Waiting for a capable PostgreSQL front-end (Score:2, Insightful)
As far as business logic, put that in PostgreSQL.
Well, in many cases of mine, programming this logic right into the form is faster and easier to manage than a full DB.
Case in point: While developing a healthcare app, I'd like to redraw part of the form that asks about pregnancies if the sex chosen earlier is 'male'. We all know males do not get pregnant for example. Putting this logic into the actual Db engine just slows things down in my opinion.
Here's another: Input masks. For example, the USA has a string of integers. On the form, I can program the mask to 'refuse' input other than 0 to 9. Or for countries like Canada that have zip-codes in the form 'A9A 9A9' where A represents an alphabetical letter and 9 represents a number between 0 and 9 inclusive, a form with an appropriate input mask is the best tool.
Though such logic can always be put into the back-end, letting the DB throw an error is typically characteristic of poor use of resources.
Agree?
Re:Cool (Score:2, Insightful)
So implementing the SQL specification is now a bad thing? The trolls know no bounds.
Re:Cool (Score:5, Insightful)
Business logic never belongs in the DB. Even triggers are suspect. They can be horribly inefficient.
The fact that triggers *can* be inefficient is no reason not to use them when there's a good implementation and competent DBAs to make sure they *aren't*. Also, business logic never belongs in the DB? To the contrary- a lot of business logic is sets of rules to maintain consistency between various things. That sort of logic is *precisely* what belongs in the DB, rather than scattered throughout a variety of applications running on top of it.
Re:"Great leap forward" (Score:5, Insightful)
Part of the reason MySQL gets treated as a toy is its release discipline- or lack thereof. At least one of the 5.x releases came out with *known* data-loss bugs; that's just not even remotely acceptable in a database, and that's the sort of impression that's hard to shake: people aren't just going to look at subsequent releases and go "oh, well, they say they're paying more attention this time, I guess that's good enough".
Re:Cool (Score:3, Insightful)
you just created a job! perhaps an entire department! great idea! well, for people that need jobs... not for people that need to pay to get something implemented correctly done for a price, or developers that take pride in the the perfection of their work and require no such additional external verification or confirmation.
Re:"Great leap forward" (Score:3, Insightful)
The fact that mysql still lets me insert "0000-00-00 00:00:00" into a datetime field is just crazy. But even more horrible and wrong is if you enter a wrong date into a datetime field and it accepts it and sets it to 0000-00-00 00:00:00. This is just plain wrong and horrible. How can a database do no integrity check. It feels like using varchar for everything.
Re:Cool (Score:4, Insightful)
I love the arguments in C++ and DB stories. They're so much better than watching two people slug it out over a football team in a bar.
Re:Thank you! (Score:5, Insightful)
Congratulations to all the Postgres developers and a big thank you from me for an amazing job! Postgres is a wonderful RDBMS and one of the best free software projects there is. Rock on!
Apart from that it now really is just about the only alternative to Oracle or Microsoft.
Re:"Great leap forward" (Score:3, Insightful)
It's not 2000 anymore. 99% of the problems people have historically with MySQL are simply not present in recent production versions. PostgreSQL and MySQL roughly have feature parity nowadays, Stop treating MySQL as if it's some toy. WikiVS has a good, up-to-date comparison: http://www.wikivs.com/wiki/MySQL_vs_PostgreSQL [wikivs.com]
Big emphasis on the "roughly". The features may look the same as tick points on a list, but when you actually try to use them, vast differences show up. Roughly bundled-together features without a comprehensive plan is what it looks like to me. For example, no referential transparency or transitive closure. You can't just nest expressions, views, function calls and procedure calls transparently. You can't alias temp tables in procedures, etc... Lots of odd restrictions and "can't get there from here" scenarios.
I also find it amusing that an AC below complains about "how many storage engines"? Whoosh, that's the sound of the point flying over his head.
By the way, I'm not dissing PostgreSQL in any way, I think it's great. But it's about time some meaningless mantras stop being chanted.
Yeah, we shouldn't expect that old bugaboo "conceptual integrity" to intrude on modern software design, right? Can't use full-text indexing and foreign key constraints on the same table? What kind of compulsive freak would want that, anyway...?
Re:Waiting for a capable PostgreSQL front-end (Score:3, Insightful)
This is because MySQL and PostgreSQL are in the same class. If you need a small, embeddable database, SQLite fits the bill better than MySQL or PostgreSQL. If you need a multi-user database and are willing to run a server, there's no technical reason to choose MySQL over PostgreSQL. And indeed, the only reasons I see MySQL being chosen are:
I see a lot less misinformation about PostgreSQL these days, just a lot of ignorance of its existence and capabilities.
Database prudes are the way we are because there's a lot riding on the decision, and people choosing MySQL almost invariably have neither the education nor the experiences we have had and simply don't understand the issues.
Re:Cool (Score:4, Insightful)
The problem wasn't that the databse was used in a wrong way.
While the database platform may have been a problem, the first, biggest problem wasn't the hardware. It was (bolded for effect): business logic does not belong in your DB, excepting a handful of cases.
I wouldn't normally have replied -- I agree with your point about hardware -- but this deserves to be underscored because so many people fundamentally do not get it.
I work for a company that was just bought out. Our new parent company develops a well known (in its industry) enterprise desktop application. The entirety of their business logic is written in the DB.
It's a maintenance nightmare, difficult to integrate with outside systems, and the system does not scale. Scalability is kicking their ass... because they can't.
Our company spends much less on hardware (and software, cheers for PostgreSQL), and our application is a billion times easier to develop and maintain. We use triggers - but only a handful.
People develop middle layers for a reason. Better code organization and flow control, much, much better speed, scalability, and flexibility.
Use a DB for what it's good at (ACID, data integrity).
Re:Cool (Score:4, Insightful)
A sincere thank you for the reply.
Respectfully, I believe you're going down a bad road. For a small application, and a developer who isn't asleep at the wheel, what you're suggesting can work OK; I imagine it hasn't been a problem for you.
Generally, for everything else, it tends to blow up down the road. And even for smaller projects, the benefits of keeping your logic out of the DB (faster, cleaner, clearer, easier to learn, easier to update) are significant.
I sincerely want to make an effort to be useful to folks who may not have worked with larger projects before. Please take this post in that spirit. It's a long, and I hope informative, post.
Make your code's intent clear ... alternatively, write logic in the right context
The biggest problem is code intent and flow control. Databases model data, GUIs model user actions, but neither necessarily model business logic. You've got business logic code for that -- like your permissions handling.
Code has a logic-centric view. Databases have a data-centric view. If you write logic in the DB, you're abstracting what you're writing from what you're actually trying to accomplish.
Error handling is a great example for flow control. Trapping an error in the DB, correctly identifying the problem and bubbling it up in a user-appropriate way in a clean fashion, as you said, is difficult.
Keep your code together
Another big problem is finding all the right code. For a newbie or a dev who hasn't looked at a bit of code in 6 months, this is very important.
Breaking your code up into different buckets based on what data it modifies makes your logic - your flow - hard to follow for anyone who isn't intimately familiar with the project.
Consider two implementations for a feature:
1) Application code triggers an update to three tables. A bunch of magic spread across several triggers on those three different tables and written in (depending on your implementation) three different schema files, or one huge file with your entire schema, updates three additional tables. E.G.: "most complex updates are performed using triggers and rules"
2) One function in one file that, in a transaction, updates six tables.
Which is easier to follow? From which implementation can you get a clear vision of the intent of the code? Which is easier to skim? If a new developer looks at your code, in which implementation is he more likely to miss something the feature touches?
Don't make interoperability harder
If you push logic into your DB, interoperability becomes harder, not easier. Before, you had just data, and two different applications could use it differently and have different requirements -- as long as what they did was consistent with the data model (your schema).
Now, with logic in the DB, anyone wanting to share your data has to work around your triggers, or co-opt them, or write entirely new triggers, procedures, and generally muck up your application to accomplish their goals.
Keep your platform flexible
Pushing logic into the DB, you may have made it easier to switch languages (although you still have a bunch of "front end" code you'd have to convert/maintain), but now it is much harder to switch databases. What was once merely data is now jumbled up with your application. If Oracle, MSSQL, etc. becomes a necessity, you're not just switching databases, you'll likely be refactoring significant chunks of your app.
Most business needs won't demand you switch languages (worst case, cross-compile or use IPC). Some business needs will demand you switch databases -- my company is now porting our app to MSSQL.
Your database is likely your bottleneck
In my experience, the first serious scalability problems most apps encounter are in the database. And the solution is always "more hardware." Beefier machines.
Then comes horizontal scaling ("moar serve