Forgot your password?
typodupeerror
Databases Software

PostgreSQL 9.0 Released 344

Posted by Soulskill
from the milestone-achieved dept.
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."
This discussion has been archived. No new comments can be posted.

PostgreSQL 9.0 Released

Comments Filter:
  • by bogaboga (793279) on Monday September 20, 2010 @07:36PM (#33643408)

    Yes first, congratulations to those folks. I am still waiting for a front-end to PostgreSQL that is as functional and easy to program as Microsoft's Access.

    I might be flamed here but there is nothing that bests Access in the open source world. Being able to program business logic into a form is something that Access and VB are pretty good at.

    What open source program can replace these two Microsoft beasts?

  • by caerwyn (38056) on Monday September 20, 2010 @07:37PM (#33643424)

    Err, have you actually used the PostgreSQL manual? It's one of the best manuals I've ever seen for a software product.

  • Re:Meh (Score:3, Informative)

    by caerwyn (38056) on Monday September 20, 2010 @07:39PM (#33643438)

    I think you've got your databases backward when it comes to integrity and verification...

  • by Anonymous Coward on Monday September 20, 2010 @07:41PM (#33643460)

    Yes, but MySQL has a shoddy parser (needs a space after the -- comment tag), poor trigger failing (you have to do a kludge and dump a varchar into an int to get it to fail), apparent lack of direction (how many forks and engines?!), no CTE support and the list goes on. I am constantly banging my head against a wall with MySQL. I use MSSQL for work, Postgres at home and MySQL on hosting.
    I am truly surprised that most web hosting companies do not offer Postgres. Postgres also allows writing of DB functions in C, Java, PHP etc. like Oracle, which is useful for bundling code into the DB (making the DB the application) without everyone having to see your SQL source for functions. It is also licensed on BSD which is good for using their libpq library in commercial apps; MySQL's C API is GPLd or licensed expensively from Oracle, although there are moves toward making it free for use in commercial apps (as far as I can tell from the mishmash of info coming from their sales rep via email).
    Also, as far as I know, MySQL puts all of its indexes in memory for replication which is a problem if the node goes down. Can anyone enlighten me?

    In any case, well done to the Postgres team. Not only is their software package neat, their documentation is some of the best I have ever seen.

  • Re:Cool (Score:2, Informative)

    by jwpye (1905258) on Monday September 20, 2010 @07:43PM (#33643478)
    Not sure if it's in other DBMSs, but it's in the SQL spec.
  • by TheFuzzy (140473) on Monday September 20, 2010 @07:45PM (#33643496)

    Why not just use .NET with PostgreSQL? You can put whatever you want on the back end.

    Or you could use Once:Radix or Servoy, both of which integrate with PostgreSQL.

    https://sourceforge.net/projects/onceradix/ [sourceforge.net]
    http://www.servoy.com/ [servoy.com]

  • by jwpye (1905258) on Monday September 20, 2010 @07:56PM (#33643612)
    hrm? The documentation is regularly updated... http://www.postgresql.org/docs/9.0/static/ [postgresql.org]
  • by shutdown -p now (807394) on Monday September 20, 2010 @08:12PM (#33643760) Journal

    It's actually one of the best manuals for SQL in general - at least, in my experience, it has the most clear explanations of many more advanced SQL constructs that are common between various RDBMSes.

  • Re:Cool (Score:2, Informative)

    by OlRickDawson (648236) on Monday September 20, 2010 @08:29PM (#33643930)
    Yes. Oracle has those.
  • Re:Cool (Score:5, Informative)

    by GooberToo (74388) on Monday September 20, 2010 @08:34PM (#33643984)

    What's the difference between logic in the trigger determining when to issue the payload logic, and the logic outside the trigger...

    No! Its far more than syntactic sugar. Performance, readability, and maintainability are what this brings to the table.

    The difference between PostgreSQL's new column trigger feature and traditional triggers is they are only called when the column is modified rather than when any row is modified. This means, in many cases, the trigger will never be called and therefore, the DB isn't having to run at PL/SQL interpreter speeds during the execution of the trigger, to then determine there is nothing for it to do. Furthermore, a big headache which is extremely common to trigger code are IF/THEN/ELSE or long CASE statements to determine which columns are modified, or to determine if the trigger even cares that the row in question (example, columns which the trigger doesn't care about) has been modified.

    The above combination of traditional triggers means lots of overhead, lots of needless PL/SQL code execution, and hard to read/maintain triggers for non-trivial actions. Whereas with the new feature, you can now have a single trigger relate to specific column, which is only ever executed when the trigger should actually execute. Its a win, win, win for all PostgreSQL users. And best of all, this means you can have smaller triggers when you need to perform different actions based on different column changes.

  • by schmiddy (599730) on Monday September 20, 2010 @08:44PM (#33644068) Homepage Journal

    Indeed. About 0.0005 seconds of Googling brought me this as the first link:

    http://www.postgresonline.com/journal/archives/24-Using-MS-Access-with-PostgreSQL.html [postgresonline.com]

    Though I think there are probably a grand total of 3 people on Earth who have used MS Access in any serious capacity and don't loathe it.

  • by guusbosman (151671) on Monday September 20, 2010 @08:46PM (#33644088) Homepage

    You know that you can point your MS Access client to any supported back-end right? Just create an ODBC connection on your Windows machine to your PostgreSQL server and you can use Access with pretty much all the features that work for the Microsoft JetEngine (PostgreSQL has ODBC drivers here; http://www.postgresql.org/ftp/odbc/versions/ [postgresql.org])

    Earlier this year we converted a huge Access application from MSSQL to PostgreSQL and the technical conversion, using ODBC to PostgreSQL instead of connecting to MSSQL, was a piece of cake.

  • Re:Cool (Score:3, Informative)

    by GooberToo (74388) on Monday September 20, 2010 @09:07PM (#33644294)

    You clearly have no idea what you're talking about. Granularity is widely accepted for such linguistic applications. The reason being, its completely applicable.

    Basically you're foolishly arguing that monster triggers are preferred over small, terse, highly readable, and much more maintainable triggers. Lots and lots of code is good. Less code which does the same thing is bad. That's simply ignorant, foolish, and FUD. "Scattering" is clearly being used to imply a negative connotation. Given there isn't a single negative with their use and that "granularity" is accepted and proper, making such statements squarely implies you're trolling.

  • Re:Thank you! (Score:5, Informative)

    by Anonymous Coward on Monday September 20, 2010 @09:19PM (#33644378)

    Thirded. There is absolutely no reason for anyone to be using MySQL any more other than the old silly excuse "my hosting provider doesn't have anything else". PostgreSQL is now faster than MySQL in all but the most trivial of contrived cases, doesn't require you to choose between table types for different load types, is just as easy to use and install, has all the features that MySQL has and runs on a Windows server (for those idiots who think that is a good thing). Also, the PG community is vastly more helpful and knowledgeable than the rabble that is the MySQL user base.

    Finally, PostgreSQL is a proper independent open source project with a structure that all other open source projects should be judged by. MySQL has gone from hand to hand in the corporate world and has a future that is far from certain.

    Down with the joke that is MySQL, and down with all the idiots that make me work with it.

  • Re:Meh (Score:5, Informative)

    by Daniel_Staal (609844) <DStaal@usa.net> on Monday September 20, 2010 @09:20PM (#33644386)

    Um, yeah. MySQL, out of the box, using the defaults, doesn't support foreign keys now. You have to specifically create the tables with a non-standard SQL code to get them to use the right database backend to get foreign key support.

    Unless you mean by 'support' 'Will silently accept and throw away'...

    Foreign keys have been enabled and working by default in Postgres since version 7. (There was no version 5...) That was released just over ten years ago at this point.

  • by Alex Zepeda (10955) on Monday September 20, 2010 @09:53PM (#33644624)

    | Please tell me you're kidding. Anyone suggesting MySql for real work should just be laughed at.

    I'm not sure how you got modded to +5 with this statement, but your statement is uninformed and completely false. While MySQL isn't in the class of Oracle for HA, MySQL with InnoDB is damn well is a competent database and I don't just mean for LAMP.

    Eh. It's *okay* for lightweight work where you don't care about data integrity or don't add or modify a lot of data. Beyond that it falls apart quickly.

    At a previous job we used ActiveRecord hooked up to MySQL to handle an influx of temporal data that was meant to be quickly processed and usable for reading back in real time. ActiveRecord uses sequences (so, auto increment fields in MySQL -- since proper sequences are lacking in MySQL) for the primary key. With Postgres this is not a problem at all. InnoDB, OTOH, locks *the entire table* to update an auto increment field. The sysadmin/dba was averse to using Postres, so the result was a series of complex and tedious to debug performance problems and queues. We spent countless hours dancing around the performance problems inherent to table level locking.

    Of course we could have gone with MyISAM... but data integrity was important. There were other seemingly basic features that were lacking in MySQL (timezone support and a useful explain command come to mind). As far as I can tell there aren't a lot of good reasons to actively choose MySQL. The lightweight cases are well handled by SQLite, and the heavier stuff will almost certainly benefit from what Postgres has to bring to the table.

  • by turing_m (1030530) on Monday September 20, 2010 @10:16PM (#33644738)

    Err, have you actually used the PostgreSQL manual? It's one of the best manuals I've ever seen for a software product.

    AFAIC, it is the standard by which other software manuals should be judged. Good call.

  • Re:Cool (Score:3, Informative)

    by afidel (530433) on Monday September 20, 2010 @10:35PM (#33644864)
    Triggers *never* increase readability IMHO, and tying features to the RDBMS rarely increases maintainability, so that leaves performance which can be enough of a reason to use them but analysis should be done to determine if there aren't other much more significant areas where the code can be optimized to bring overall system performance up to where they are unneeded. Then again most of the software I do care and feeding for is platform neutral COTS that can be run on any of MSSQL/Oracle/DB2 with Postgres or *shudder* MySQL sometimes being options. We do little inhouse coding and what little we do is usually running through frameworks like IBM's Castiron or Oracle Fusion so it's again platform neutral.
  • by JohnnyBigodes (609498) <morphine@digita[ ]nte.net ['lme' in gap]> on Monday September 20, 2010 @11:26PM (#33645242)

    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]

    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.

  • by greg1104 (461138) <gsmith@gregsmith.com> on Monday September 20, 2010 @11:39PM (#33645320) Homepage

    The servers Sun supplied that Oracle recently yanked were for the regular PostgreSQL build farm, used to run basic regression tests. They've since been replaced, the project is unmoved. As I mention in more detail in my upthread post, work on the PostgreSQL performance farm continues unaffected by that. It is expected that some build farm machines will also run the performance farm client periodically too, that's the only overlap there ever was between the two pieces of work. If Oracle still had hardware in the build farm it could have been used for performance tests too eventually. But they don't, and we in the PostgreSQL community don't care; we don't need their contributions.

  • by TheRaven64 (641858) on Tuesday September 21, 2010 @07:33AM (#33647486) Journal
    Not sure about FaceBook, but Google's uses of MySQL are quite limited. They use their own BigTable for all of the serious stuff.
  • Re:Haha (Score:2, Informative)

    by georgeb (472989) on Tuesday September 21, 2010 @08:13AM (#33647800) Journal
    Ok GP offered a valid technical criticism of a database (one component in a bigger project) and your solution, typical for MySQL users and developers I might add, is to change the other components of the project. Cool. Glad to see you give constructive feedback.
  • by Decibel (5099) on Tuesday September 21, 2010 @09:05AM (#33648370) Journal

    The Feb 30 issue gets *even better*. For years I used that as a prime example of what's wrong with MySQL, so I was a bit disappointed when I found out they'd fixed it.

    Then I discovered that Feb 35th is *STILL* a valid date! The only thing they fixed was Feb 30th and 31st!

    MySQL clearly just doesn't get it.

Prototype designs always work. -- Don Vonada

Working...