PostgreSQL 8.4 Out

TheFuzzy writes "PostgreSQL version 8.4 is now out and available for download. The main cool features in this version are: recursive queries (for doing trees etc.), windowing functions (for doing reports) column-level permissions, parallel database restore, a beta in-place upgrade tool, and a host of administrative improvements. And, of course, better performance, mainly on reporting queries. Some of the over 200 new or enhanced features are listed here."

Comments

So why

[jlechem]

Does anyone even use mySQL when they have features like this? The only issue I have ever had with this DB was when I was trying to connect a .net app to it and it took me a while to find a workaround.

Re:So why

[XanC]

Not one of these features is remotely compelling enough to switch an existing, working app from MySQL.

Re:So why

[Mad Merlin]

Does it have built in replication yet?

Re:So why

[ducomputergeek]

No, but Oracle taking over MySQL and the community already showing signs of forking in 4 different directions might be a reason to seriously look at PostgreSQL.

Re:So why

[Foofoobar]

Nope... I was planning on continue to stick with MySQL as MariaDB is going to bring much needed improvements to the project

Re:So why

[Anonymous Coward]

No, the replication and hot standby patches were not considered of high enough quality to be a part of 8.4. They will be a high priority during development of 8.5.

PostgreSQL would never, ever ship something which has a WTF-list as long as MySQL's replication does: http://dev.mysql.com/doc/refman/5.0/en/replication-features.html

Re:So why

[Phroggy]

Does anyone even use mySQL when they have features like this? The only issue I have ever had with this DB was when I was trying to connect a .net app to it and it took me a while to find a workaround.

Because I don't need features like this, and don't know how to use them. At least, as far as I know, I don't need features like this. Since I don't know how to use them, it doesn't really matter, does it?

MySQL is what I've been running for several years; I'm familiar with the software. I use DBD::mysql in my Perl scripts; I'm sure most things would work fine if I simply switched to DBD::Pg, but would any queries need to be changed? I have no idea. Of course I'd need to migrate my data from MySQL to PostgreSQL; I'm not even sure of the "correct" way to migrate data from one installation of MySQL to another (copying the data files and then fixing whatever's broken usually works well enough). Of course, I'm running a few PHP-based webapps that currently use MySQL; I don't know if it's possible to get them to work with PostgreSQL or not (switching database engines in PHP isn't as simple as it is in Perl).

I could take the time to do the research and find answers to these questions. Or I could keep using what I know works just fine. Maybe someday I'll have some compelling need to try PostgreSQL and see if switching is practical. Today is not that day.

Does this answer your question?

Re:So why

[Anonymous Coward]

I'm currently stuck on mysql because Postgre has no support for connections over windows ipc pipes.

Re:So why

[temojen]

Because most common web apps are only built on mySQL, because most ISPs only have mySQL, because most common web apps are only built on mySQL...

Re:So why

[Anonymous Coward]

I tried to use it for the project I'm currently working on, but I could not find an ultra-cheap provider (>=$5/month) that had it as an option. If anyone knows of a decent cheap host that offers PostgreSQL I would gladly switch; I signed up on a monthly plan with the hopes of being able to switch. (Although now that I've re-written everything, it's not as imperative.)

Re:So why

[ByOhTek]

Rabit -> rabid...

Damn typo daemon.

Either that or the postgress fanbois really are getting all the chicks and I am on the wrong bandwagon.

Re:So why

[Just Some Guy]

Honestly, the more rabid and on-the-offense a community gets, the more a am suspicious of the product.

First, the only on-the-offense part was a list of new high-end features. Second, it's pretty easy to become rabid when you try to tell people about your quad-turbo Ferrari dumptruck that does 0-60 in 4 seconds fully loaded and pulls 1.5g on the skidpad while getting 137 miles per gallon, but keep getting shouted down by Kia Fanbois who make fun of every feature your truck has that they don't - until they get a half-assed version of it and then act smug like they invented it.

PostgreSQL fans have nothing on rabid MySQL fans, I promise you.

Re:So why

[zehaeva]

PHP supports PostgreSQL its as simple as doing a global find-replace of mysql_ with pg_ there done. Okay a bit too simple but the mysql functions and the pg functions have the same names other than the prefixes and they behave in the same exact manner. You may need to change a little bit of SQL.

Once you get to start to use the more advanced features of postgresql you'll look at mysql more as a toy rather than a fully featured RDBMS.

It's rather like when you first started playing with mysql and went "Wow, this is so much better than Excel!"

~Z

Re:So why

[CarpetShark]

In theory, I too was much in favor of PostgreSQL over MySQL, for many years, until VERY recently, when I actually got around to using it for serious projects. Then I discovered that pgadmin on windows can't even backup a PostgreSQL server unless the versions match EXACTLY (minors as well as majors) across builds and platforms. That's pretty insane. I'm now worried about what other seemingly obvious issues might not have been addressed in pg.

Re:So why

[0racle]

You stopped using a DB system because a app related to but not developed by PostgreSQL didn't do something you wanted it to? I stopped using Oracle because I didn't like the colour scheme in Toads tools. No seriously, I say that with no hint of sarcasm.

For a serious project, I would expect someone to use scripts anyway.

Re:So why

[mvdwege]

Eh? Why would that be a problem? Just use the supplied backup & restore tools (pg_dump and pg_restore), they work just fine. If you really can't back up a database without a pointy-clicky GUI, you have no business being a DBA.

Mart

Re:So why

[NormalVisual]

that, and the fact that four years later from the original bug report, stored procedures still can't even find out what caused a thrown exception, with no indication that they even give a damn about it. Working with stored procs under MySQL is a frigging joke.

Re:So why

[Dan Ost]

Fortunately, it's getting much easier to find a hosting provider that offers PostgreSQL. Of course, if you just rent a bare machine and install your own image, you've always been able to install PostgreSQL.

Re:So why

[Dan Ost]

I believe this is by design.

Dumping it from one database and loading it into the other will always work, and, I believe, is the recommended procedure.

Re:So why

[CarpetShark]

pgadmin is the official frontend to pg_dump. Since you've no clue what YOU'RE talking about, I hope you're not a DBA. I'm not, by the way.

Re:So why

[Anonymous Coward]

Looking at pg_query_params() and never worry about sql-injection again might also be a good idea.

Re:So why

[MBGMorden]

I'll concede your point, but the original poster did state that his app was working fine as is with MySQL. If the app is simple enough you might simply not have to use stored procedures at all.

Truthfully though, I'm not sure what keeps drawing users back to MySQL as a default. As the OP stated, it's often not worth the effort to switch a working app to a different database (and I've still got one application hitting a MySQL database because it works fine - all it does it let the company secretaries enter in phone calls that their bosses receive in a help desk type fashion), but I can't fathom why anyone chooses it when starting out from scratch anymore. PostgreSQL works great, and is just as easy to use. MS SQL Server (which despite the MS haters really isn't that bad of a DBMS) is also available in the Express version which is also a very easy to use and robust system as well. I'm sure Oracle is a great choice too but I simply haven't had any experience with it so far (it's not free and my employer strongly prefers MS SQL Server for everything so I simply haven't had a chance to play with it).

To me MySQL is simply a legacy system. I'll keep it for as long as I need, but anything new will use something different.

Re:So why

[Foofoobar]

wow. That didn't sound rabidly defensive at all. Not in the least.

Re:So why

[h4rm0ny]

You have given what is, I believe, the most common reason for not switching: MySQL works well enough for what you need so it doesn't make sense to expend additional time and effort (you probably don't have much of the former) to learn something that you will only use for the same purposes. It makes sense.

But in a friendly response, I'll just mention that once you are familiar with PostgreSQL, you will be aware of what more you can do with it and that may lead to the second part of your logic (you will only do the same things with it) to become false. Because you'll find opportunities to do things in different ways that you may prefer.

Also, you can become one of us super-annoying people on Slashdot who keep talking about why PostgreSQL is better than MySQL. ;) Really, you don't need to learn PostgreSQL if MySQL is meeting your needs. But you might find it fun, more useful than you might have thought, and you wont magically forget your MySQL knowledge so it's not as if you're compelled to seek out only jobs and projects that use PostgreSQL.

Just some general comments - not a dismissal of what you've said.

Regards,
H.

Re:So why

[jalefkowit]

PHP supports PostgreSQL its as simple as doing a global find-replace of mysql_ with pg_ there done. Okay a bit too simple but the mysql functions and the pg functions have the same names other than the prefixes and they behave in the same exact manner.

... or you could just use PDO, the way God intended.

Re:So why

[grcumb]

Either that or the postgress fanbois really are getting all the chicks and I am on the wrong bandwagon.

I'd reply to this, but my Postgres DBA is here, working on my equipment. Before she got her PhD, she was an Olympic gymnast. She can suck the chrome off a trailer hitch and gives a whole new meaning to the phrase 'hot swap'. Now, if you'll excuse me, I have some... uh, maintenance to perform.

Re:So why

[rasherbuyer]

The only reason there are comparisons between MySQL and PostgreSQL is because they are both Open Source. Otherwise there is no comparison.

PostgreSQL is a fully featured, enterprise ready, RDBMS and stands for comparison with Oracle and DB2 and to a lesser extent Sybase/SQL Server. MySQL is not even in the same league as any of the previously mentioned. However, web developers seem to like it...

I'll show my colours and say that I've been working with Oracle for over 10 years, and I love it, it gets better all the time. I can't comment on DB2 as I haven't used it for about 10 years and then only briefly.

I've just finished managing a six month data migration project from SQL Server to Oracle. Oracle is head and shoulders above SQL Server in the query stakes and stomps all over it with it's procedural language (PL/SQL vs TSQL). PostgreSQL is much more Oracle-like than anything else, pl/pgsq is even comparable with PL/SQL although not as feature rich.

I recon the Postgres guys are at least at a par with 8i comparing against Oracle, which is pretty damned impressive.

Re:So why

[Estanislao Mart�nez]

Not one of these features is remotely compelling enough to switch an existing, working app from MySQL.

Sure, let's grant that, for the sake of argument (though I'd say that most of the time it is true). Now, why do people keep developing new applications to use MySQL?

I can never get a good answer to this question. The answers I tend to get are of the form "because they don't want to spend the time to learn a new RDBMS." These people tend to spend a lot of time cleaning up after MySQL's flaws on applications that they inherited, too.

Re:So why

[h4rm0ny]

Yeah, but kind of funny though. ;)

Re:So why

[zehaeva]

I would have hoped that he would be using parameterized queries to start with.

Re:So why

[digitalunity]

It's pretty much spot on though. When a new feature comes out for MySQL, the fanatics love to shove it in your face, even if the real RDBMS have had it for years.

PostgreSQL does everything mySQL does, but better. I would have thought great unicode support alone would be enough to sway the mySQL believers but I was wrong. Now I don't even debate the issue unless I'm sure I am even talking to a reasonable human. The whole mySQL vs. PostgreSQL debate usually descends into the mud quickly with neither side listening to the other.

I'll stick with PostgreSQL, thank you very much.

Re:So why

[h4rm0ny]

I was about to predict some abuse coming your way, but I see it's already appeared. : /

If PostgreSQL is not for you, no problem, but seriously, just using pg_dump would be the proper way to do this and it seems a shame to change to a different database if that's the sole issue. </friendlycomment>

Re:So why

[Anonymous Coward]

was not aware that God endorsed programming objects! kidding aside I'm kind of suck in php4 land. ignoring that there is something about using OOP for what boils down to a run time script that i find odd. does data encapsulation and all the other oop goodies really help you? i find it to be a bit overkill for most websites. also given how loose php is with data typing and other features it really seems .. inconsistent? i don't know, i just never felt a real good warm and fuzzy by using oop in php. maybe if it were stricter with its constructs or maybe if i used it for a more robust application than "grab data from db push to webpage" i'd like it more. sorry for the wall of text.

Re:So why

[Morgon]

I don't know, I think windowing functions are pretty significant,
Sure, it depends on whether you have an app that benefits from them, but assuming you do, it's pretty significant. Doing sub-sorts on large datasets is a killer without functions like these.

Re:So why

[AKAImBatman]

LunarPages is around that range and they provide both PostgreSQL and MySQL as options.

Re:So why

[digitalunity]

Maybe you can relay back to Oracle please that the eBusiness java interface is god awful slow.

Thanks. You might have more sway than I do.

Re:So why

[HeronBlademaster]

My former employer uses PostgreSQL because it's about a bazillion times better at handling large (read: several hundred GB) tables... and even then we made pg run out of internal row OIDs and we had to tinker with pg's innards.

Yay for large data sets!

That said, I use MySQL for small projects because I can't be bothered to set up Postgres on my server.

Re:So why

[Second_Derivative]

To answer your question:

SQL Server's development tools are top notch. Admittedly, that says more about the quality of the competition than anything else, which I'll come to in a moment. The DBMS itself is a bit iffy though. SQL Server 2000 and below are just a complete joke in terms of features and performance (and some shops still run it!). 2005 is pretty good, but they bolted on MVCC sideways and it shows. You can turn on MVCC on most operations, but I've had such a lot of hassle trying to alleviate weird locking issues that you end up just sprinkling SET TRANSACTION ISOLATION LEVEL SNAPSHOT; and WITH (ROWLOCK) or WITH (NOLOCK) everywhere just to get things done. That and it just does really unusual things sometimes. For instance, the latest performance tweak I had to apply was to add an index to a 30MB table which was for all intents and purposes read-only, . This is on a database server with 8GB of RAM installed, and that table is read from a _lot_. Why doesn't it live inside the block cache?

Oracle, on the other hand, have a very powerful database engine at the core. I get far fewer instances of query planner strangeness than I do with SQL Server. However, it is completely and utterly bloated beyond belief... I suppose that's to be expected from a codebase that's probably older than I am, but some omissions are really quite annoying. For instance, you can't, as far as I am aware, create temporary tables on the fly, you need a DBA to create them for you, despite the fact that most heavyweight queries are going to end up scribbling into the tempdb anyway, so I don't see why this needs to be a priviledged operatoin. Also, returning result sets from stored procs is just painful. SQL Server just lets you SELECT like normal, with Oracle you have to use SYS_REFCURSOR OUT variables, which is a lot more cumbersome, particularly from an administration frontend.

Oh yeah, Oracle doesn't come with any decent frontends of its own, so you have to use third party ones. In our shop we use a couple, but one of them is TOAD and it the one piece of software I hate the most, out of everything I have ever used. This is enterprise software at its finest, with about four or five toolbars full of shit and a catalogue of features that I'm sure their victim^H^H^H^H^Hclients' purchasing executives absolutely drool over. This thing has an HTML editor built into it. It's got _x86 assembly syntax highlighting functionality in its text editor_, for crying out loud. You know, just in case you fancy writing a nifty bootloader in between bouts of PL/SQL (I was rather disappointed to note that it only supported 16-bit real-mode instructions and registers. Oh well). It has an absolutely dizzying array of knobs and dials and options in its settings menu, which as a whole are about as clear as mud. But forget doing any sort of actual basic SQL work with this thing, because it's not going to happen. There are three ways to issue an SQL command, for no particular reason, and a whole bunch of crazy rules to pick which one to use. Sometimes, none of them even see fit to tell you exactly where the PL/SQL error is in the package body you just tried to compile. Some of these invocation modes block the UI while it's talking to the db. It likes to hang on db operations a lot in general; during autocomplete, during result set seeking, during some completely unrelated operations whose nature I cannot fathom. Also, it seems to get wedged if you enable DBMS_OUTPUT to one of its multitudinous window panes, but maybe I was just doing something wrong there. Urgh. I hate this utter piece of crap.

But yeah, as for Oracle itself, it's extremely powerful, if a little verbose and unwieldy. A consultant's dream, I suppose. Given the choice though, I would actually use PostgreSQL for most projects as opposed to either of those two. It's got MVCC built in from the ground up, it's not blazingly fast but its performance is a lot more consistent than some of its competitors, in my (admittedly very) limited experience with the database, its tools are clean and lean, and generally it seems well engineered and no more complicated than it needs to be.

Re:So why

[Anonymous Coward]

pgAdmin calls pg_dump to backup the database, which is what is strict about ensuring the versions match (for good reason), but pgAdmin offers two options to deal with this. You can specify the path to the required version of pg_dump (obviously, you may not be using the verion that pgAdmin ships with), or there's an option to override the pg_dump version check.

Re:So why

[jadavis]

git repo
Design spec

This is the feature that didn't quite make it in 8.4. Look at how much effort and research went into the design. This isn't a situation where someone threw some code together; this is real design and real code by a highly reputable hacker, that answered feedback from other highly reputable hackers.

The only reason this didn't make it is that PostgreSQL has a reputation for getting things right (really right), and that's more important than one feature.

But try it out. If the code hasn't rotted too much, it should work fine.

Re:So why

[Timothy Brownawell]

Also, it [Toad] seems to get wedged if you enable DBMS_OUTPUT to one of its multitudinous window panes, but maybe I was just doing something wrong there. Urgh. I hate this utter piece of crap.

When polling for dbms_output is enabled, and it tries to poll while a query is running, it freezes until the query finishes. When there's a huge amount of output to fetch, I think it also freezes while fetching it.

Re:So why

[Anonymous Coward]

Woah, I thought you were talking about Apple there...

Re:So why

[Foofoobar]

I love how people still say PostgreSQL does it better and yet it is still slower, I can't do cross database joins easily, I can't do cross NETWORK joins, it's functionality is still limited in comparison, etc. MySQL is like Firefox and Apache... FLEXIBLE. It can meet the demands of what you put it to and not anal retentively rigid. MyISAM is faster because it is not rigid but puts the ACID compliance on the application. If you need transactions and ACID then move to InnoDB... or Mix the two. I can have tables of one kind and tables of the other, join across multiple database on multiple networks, etc. Postgresql would rather die before becoming this flexible. It prides itself in being rigidly compliant to a standard rather than an evolving tool.

Yes, MySQL evolves and that is why we have the forks and that is why we are having MariaDB be born. And most of us look forward to it.

Re:So why

[Anonymous Coward]

It only takes a minute, and a package manager makes it trivial.

Re:So why

[digitalunity]

MySQL, for all it's so-called flexibility, has abysmal indexing capabilities. It's unicode support is far inferior. MySQL might be faster on a connections per second rate, but falls behind on update speed.

I'm not oblivious to PG's inferiorities though. I guess the biggest issue is that PG's replication is inefficient compared to MySQL.

Re:So why

[nemesisrocks]

Does anyone even use mySQL when they have features like this?

That's easy, and can be answered in two words: first impressions

Like it or not, when you're marketing to the masses, first impressions count. With database systems, a good chunk of your userbase will be ex-Access or ex-MSSQL users. Postgres, while it's a technically fantastic database, sucks on first impressions, and the mindset required is significantly different to Access or MSSQL. "Schema" instead of "Database", and defaults to fairly restrictive permissions, making first-time use a bit of a hurdle.

MySQL on the other hand has a decent Windows installer, some great tools to manage the DB, and doesn't require a large shift in mindset to get apps up and running against it. And once they've installed and have a few apps running MySQL, they're far more likely to continue to...

Re:So why

[turbidostato]

"the original poster did state that his app was working fine as is with MySQL."

So he thinks. From past experience I'd bet he simply doesn't know better.

"I've still got one application hitting a MySQL database because it works fine - all it does it let the company secretaries enter in phone calls that their bosses receive in a help desk type fashion)"

And since you are using MySQL all your referential management is done in code (phone table should have person's id column as a foreign key from persons table, for instance). Not only it makes it more bug-prone but it makes it more difficult to modify or add new features.

Re:So why

[turbidostato]

"Really, you don't need to learn PostgreSQL if MySQL is meeting your needs."

The real problem is that MySQL only *seems* to meet some needs because the one with them doesn't know any better.

Nine out of ten times (to say the least) when somebody has told me "but MySQL covers my needs" it turned out he had no idea what their real needs were and what were the tools he could use (both "real" and logical) so he could pick the best fitted.

While ignorance is a reason, it's not a very glamurous one.

Re:So why

[Sxooter]

Your arguments ring hollow. In PostgreSQL, using schemas within a database, you get the same basic functionality that MySQL does. I.e. what is a database to MySQL is a schema to PostgreSQL. And you can do cross db / cross network queries, but they are uglier since you have to use dblink or pl/proxy.

OTOH, if you crank up innodb and start doing crossdb transactional queries, guess what? They're not really transactional. Half the transaction can fail and half can succeed and your data is now incoherent.

I have to say I find pgsql far more flexible than MySQL. And you can't put ACID in the app. Sorry, but whoever told you that works lied to you.

Also, take a MySQL server in mid transaction with it's wonderful mixed table design, and pull the power plug / trip a circuit breaker / have some idiot at the hosting center power everything down and you can spend a day or two bringing it back up and restoring your data. I'll just turn my PostgreSQL server back on and keep going.

How many pl languages does MySQL support? I can name over a dozen for pgsql.

Also, I'd rather my database yell at me for trying to insert "stan" as a date and just silently turn it into '0000-00-00'. Or try to insert 123876348763 into an int4 and have it silently truncate to 2^31-1 on me. But hey, that's some flexibility, eh!

Re:So why

[Sxooter]

s/inefficient/reliable/

Re:So why

[Sxooter]

No, it's not. Whoever told you that lied. The official front end to pg_dump is bash. or csh, or tsh, or ksh. And yea, if you can't drive a database without pointy clicky you should get a job with lots of round, non-sharp objects so as not to hurt yourself or others.

Re:So why

[Sxooter]

Have you used a recent version of pgsql with the windows installer? It's really quite nice.

Re:So why

[neoform]

Where can I find these rabid MySQL fans? I use mysql and have never met someone that has claimed mysql is better than postgresql, but I never hear the end of it from postgresql users..

Re:So why

[rycamor]

Not one of these features is remotely compelling enough to switch an existing, working app from MySQL.

Maybe not the new features, but all the good features that PostgreSQL already had were plenty reason for me to switch my MySQL apps. I suppose it depends on your definition of 'working'. I found that modeling and enforcing constraints in application code instead of in the database was becoming prohibitive for any application of decent complexity. Of course, I know that there are two camps on that issue, and the OOP/Framework crowd (Ruby on Rails, DJango, etc...) tend to take the philosophy that the database is just a collection of table stores and all the intelligence belongs in the app.

I say "philosophy" rather than "opinion" because the difference deserves more respect. My meta-philosophy is that there are apps which work well that way, but there are many scenarios where database-oriented constraints provide much better long-term quality assurance.

Re:So why

[rycamor]

RPF: Rabit Postgres Fanbois.

Honestly, the more rabid and on-the-offense a community gets, the more a am suspicious of the product.

Why be suspicious? It's pretty easy to get actual knowledge of what the product does without regard to fanbois or flamers. I don't make any choices for or against a product based on that. Also, if you browse the PostgreSQL mail lists, I think you'll see very little rabid-ness. You *will* see an intense dedication to quality, especially if you read the core developers' lists. Quite interesting discussions, there.

Anyway, isn't it just a little disingenuous to come to a PostgreSQL thread, and then accuse PostgreSQL supporters of being rabid? When something cool and new and shiny comes out in your favorite [whatever], don't you tend to get a little exuberant? Let them have their fun, and save the that stuff for a MySQL-vs-PostgreSQL thread.

Re:So why

[jadavis]

I can't fathom why anyone chooses it when starting out from scratch anymore.

The excuses are quickly running out, that's for sure. Lack of "easy" master/slave replication with readable slave is probably the only serious complaint.

Even in that case, it's not like you can't do it, but it will be a challenge. Slony is my favorite of the current systems (assuming you have to read from the slave), but "easy" is not one of its strong points. Robust and flexible, but not easy.

I might say that SQL standard MERGE would be another thing to make coming from MySQL a little easier (not that MySQL supports MERGE, but it does have some funky ON DUPLICATE key syntax that's better solved by MERGE), but that's a pretty minor complaint.

On the whole, it seems harder and harder to imagine starting a new project with MySQL. If it's a small project and I'm looking for "easy", replication is unnecessary. If not, then PostgreSQL just has so much to offer that makes your life easier through the entire lifecycle of a series of applications that use that data. In that case, learning slony well enough to make it do what you want might be a good investment of all the time you save.

Re:So why

[Foofoobar]

shows how little you know. Talking out of your ass I see. But hey, who am I to correct someone who THINKS they know what they are talking about when talking about MySQL in the sense of a 1990's version of the RDBMS rather than a present version. One could do the same about Postgres too but I'm not going to descend into your idiocy. Postgres has come a long way from being the buggy slow peice of crap it used to be and is actually a very reliable RDBMS. It just isn't very flexible.

I would also suggest learning more about MySQL before opening your mouth as well if you plan on looking intelligent anytime soon.

Re:So why

[ducomputergeek]

We've always used PostgreSQL for development when the plans were to move to an enterprise class HA cluster down the road. Usually if it worked well in PostgreSQL, things really worked well when we moved to DB2 or Oracle.

Re:So why

[Sxooter]

I would agree that none of the new features would make switching from MySQL to PostgreSQL compelling. OTOH, the features PostgreSQL has had for quite some time ARE compelling to switch. Like storing the db meta data in transaction safe tables (pgsql) versus storing them in non-crash / non-transaction safe tables (MySQL). Or making sure that what you put in either goes in or throws an error without mangling the data (i.e. MySQL inserts 'stan' into a timestamp field as 0000-00-00 00:00:00 a non-existent and nonsense value, or inserting 2^31-1 for a value overflowing a 4 byte int, etc) Or the fact that MySQL still has issues with multibyte encodings, or that you can't have full text indexing on transactional tables like innodb. Or the fact that MySQL has serious and known bugs that haven't been addressed for years. Or the fact that MySQL has added known bugs to production releases because their QA is crap, for example, the order by DESC bug with regards to innodb tables, which showed up, got fixed, then showed up again all in the 5.0 GA release.

In fact, I'm really hoping that the community just takes MySQL away from Oracle / Sun / MySQL AB and fixes it and maintains it as a pure GPL only product. It deserves better treatment than it's gotten in the past by MySQL AB and their shoddy release practices. So far, the signs are good that that may in fact happen.

Re:So why

[Sxooter]

I think it might be worth examining the differences between the two dbs. I've found some truly compelling things about pgsql. Here's a short list of the things I really like about pgsql:

Transactional DDL statements. Sounds kinda trivial, but it lets you do things like alter a table, update a field, and then, if things go horribly wrong, you can roll it back. For production updates, this can be a life saver. In pgsql everything except create / drop database and create drop tablespace are transactable.

The CTRL-C works like it should in psql, it cancels the current command. The fact that it exits the session in mysql's command line tool is idiotic, and should have been fixed years ago.

Fast and reliable bug fixes. I'd say the average time a nasty bug (crash, wrong results, data corruption) is fixed is within one to two days after it's found. There aren't a lot, but when the pg crew finds out about one, they stomp it fast.

Re:So why

[Sxooter]

Really? I've found there to be plenty of rabid fanboi types on both side of the fence. Pgsql users often still have a chip on their shoulder from the totally slanderous statements MySQL AB used to make about PostgreSQL, and they made a lot of them, and for a long time, it stuck, and I heard them repeated over and over from mysql fanbois.

I tend to ignore fanbois on both sides of the fence and consider the two positions based on reason, evidence, experience, testing, and support. I find that pgsql beats mysql on most all those accounts. But I've used both a fair bit before, so I have a basis for comparison.

Healthy suspicion is a good thing, it keeps us away from things like porcupines. OTOH, relying on just suspicion won't get you very far. Try it out, see how it really works. That applies to everything, not just databases.

Re:So why

[Sxooter]

What's the current GA? 5.1. Can you do cross db transactions in 5.1? No. Sorry, but you should really learn more about the db you're a fanboi of if you're gonna tell me I'm talking out my ass. Sorry, but no one's making you look stupid but you.

Re:So why

[Sxooter]

Holy shit! I just tried it and amazing, it does work. Wow. I remembered using an old version where that wasn't the case. Well, I guess I was wrong.

Re:So why

[Allador]

MS-SQL's query planner and core engine may not be as mature and advanced as Oracle's, but it's still orders of magnitude better than MySQL and PostgreSQL in my experience.

Especially the former. I can run queries in MSSQL that does an inner join on 12 tables, none of which have less than a million records, and get a result in far less than a second.

Compare that to MySQL, where if you use a WHERE IN clause, will largely tend to go into an infinite loop and never finish, even on tiny tables and recordsets.

Once you get past the most basic of basic one-table CRUD operations, you really see how incredibly primitive MySQL is.

Sadly though, MySQL ends up being completely adequate in a lot of situations, as long as you're willing to adapt report-query writing and your style to its incredible limitations.

Re:So why

[Allador]

I love how people still say PostgreSQL does it better and yet it is still slower,

Slower at what? Sure, MySQL may be faster when doing a single table select with a simple where clause on an ISAM table.

But then it utterly breaks down when you want to do things like join a bunch of tables together, or do sub-queries or WHERE IN clauses. I can make MySQL go into an infinite loop using an extremely simple 'where in' subquery on tiny tables. This is a bug thats been in the system and known for YEARS, but never fixed.

MySQL is horrendously slow at the kind of sql queries that surpass single-table selects.

Re:So why

[h4rm0ny]

Well I did say that once he learnt PostgreSQL, he'd probably find that MySQL no longer met his needs simply because he realised what more was possible. ;)

By the sounds of his other posts, he's not doing much more than using databases for a bit of data persistence for websites, in which case, admirer of PostgreSQL that I am, he's still probably right that MySQL meets his needs. It would open more doors for him if he knew PostgreSQL, of course. But equally he could be learning Python, perfecting his golf or playing with his kids. PostgreSQL is quite frankly, great. But he who fights fanboys must be careful, lest he himself becometh a fan boy. ;)

PostgreSQL's feature list and reputation speak for itself. I prefer to evangelise gently. ;)

Re:So why

[rvw]

Take a look at the new PGAdmin. One of the great improvements is a visual query builder, similar to MS SQL Server Management Studio. I've only tested it for a few minutes, but it looks promising!

Re:So why

[TheRaven64]

My first impression of MySQL was trying to do my undergrad databases coursework in it. The coursework was designed for MS Access, but we were allowed to use other databases if we wanted. I'd heard of MySQL, so I tried it. On Question 2, it started giving me errors for things that looked like valid SQL. I tried some of the examples from the notes, and they failed too. It turned out that MySQL, at the time, didn't support foreign keys. Considering how fundamental a feature this is (i.e. really, really basic SQL support) I gave up on MySQL and tried PostgreSQL. With Postgres, it worked perfectly and I completed the coursework. I've since used Postgres in a few projects.

I hear MySQL has improved recently, but I wouldn't trust my data to something that claims to be an SQL RDBMS and only recently got foreign key support. For things that don't really need an RDBMS, there's SQLite, which is simple and fast for basic queries. For things that do, there's PostgreSQL, which is more complicated, but full-featured and fast for complex queries. There may be a niche between the two where MySQL fits, but I've not found it.

Re:So why

[salesgeek]

There are places for both strategies, and it really depends on if you are going to have multi-application access or allow third party apps into your database.

Re:So why

[Carik]

Here's an answer I consider to be a good one.

I'm not developing any major applications: generally I build things that could just as easily be kept in a spreadsheet, if only I didn't want want it to run on the server, with a web interface. If I already know mySQL, why should I spend my time learning a different interface? MySQL does everything I need.

If it's what you know, and you have no problems with it, it's good enough.

That said... I'm looking at rebuilding one of my earlier apps, and there's functionality in Postgres that will be useful to me, so I'll probably end up learning that soon. MySQL has been more than adequate for my hobby use for six or seven years, though... I'm only finding a use for Postgres now that I'm building apps for a larger scale environment.

Re:So why

[Carik]

'It's rather like when you first started playing with mysql and went "Wow, this is so much better than Excel!"'

Personally, I never found that mysql (or postresql, for that matter) is better than Excel. They're useful for totally different things.

If what you want is a large relational database, then yes, using a relational database instead of a spreadsheet is better.

If what you want is a spreadsheet, then using a relational database doesn't make much sense, and is a lot more difficult.

Re:So why

[zehaeva]

I agree that they are different tools for different things, however I have seen people try to use Excel in ways that would have been trivial with a RDBMS. It seems very easy to let a simple spreadsheet blow up into something that should be a a db but the office worker never new that RDBMS even exist. I was trying to tap into that feeling.

Re:So why

[Carik]

Yes... but a lot of us don't NEED to do more than single-table selects.

Sure, if you're doing professional work with huge dbs, Posgresql is clearly superior. If you're doing something simple with small tables, why not just use mySQL?

Re:So why

[rasherbuyer]

I'm afraid my experience is purely SQL and PL/SQL - I have no opinion other than on those subjects.

Re:So why

[TheLink]

I far prefer Postgresql to MySQL, but while doing everything in the database is often "neater" it usually makes it more expensive to scale.

If you let the DB do most of the work when the DB runs out of grunt it often costs $$$$$$$ to make faster.

If you let the app servers do most of the work, when the app servers run out of grunt you add a bunch of app servers for $$$$$. Big diff.

I know the DB people will say a lot about maintaining data integrity etc.

Sure use the data integrity stuff whenever it doesn't really cost the DB anything (paid for already, or only a little cost), but once you start adding lots of stored procedures and triggers, rules etc, you better be aware that scaling up a database server often costs a lot more money.

No problem for small businesses that are going to grow to medium sized businesses - since Intel, Seagate and friends are already well on their way to taking care of your future needs. They might already have stuff for you today, that you need tomorrow.

But if you're intending to be _huge_ in the next few years, it's not going to be cheap. People can say all sorts of things about database clustering but please check the ugly details first there are often lots of limitations and gotchas.

So basically you'd want to keep the load on the DB low enough so that you can avoid the messy expensive scenarios as long as possible.

e.g. No problem if by the time you need a fault-tolerant DB "teraflop" server with 1TB RAM and 10GB/sec IO, Dell and friends are selling them for about USD2999.

Whereas if you need a fault tolerant DB that needs 10TB working mem, 100GB/sec IO and "terahurts" of performance, _TODAY_, it's going to cost you.

Re:So why

[Anonymous Coward]

Don't worry. MySQL could break it in the new version just for you ;).

Re:So why

[TheLink]

Inefficient?

See: http://dev.mysql.com/doc/refman/5.1/en/replication-features-auto-increment.html

Quote: Prior to MySQL 5.1.12, when a stored routine or trigger caused an INSERT into an AUTO_INCREMENT column, the generated AUTO_INCREMENT value was not written into the binary log, so a different value could in some cases be inserted on the slave.

Using replication written by people who regularly release stuff of such "quality", is being inefficient - you'll eventually be wasting a lot of time.

A prev company I worked for stupidly used MySQL for a lot of stuff and I'd say it has cost them quite a fair bit. They've had lost data, corrupted data and server crashes (not hardware related).

Re:So why

[digitalunity]

My "inefficiency" comment was directed at PG. I-slony replication doesn't scale well. It works awesome if you only have 1 or 2 slaves, but replication between many servers doesn't work good.

Re:So why

[Anonymous Coward]

But does replication between MySQL servers actually "work good"?

To me it's not replication if some rows get inserted with different autoincrement numbers on the slaves... Fixing this is not always just a matter of copying the master to the slave. It's a lot harder to fix if some 3rd party disagrees with your preferred version of reality...

Re:So why

[jadavis]

I always thought postgresql was a little more "developer friendly", at least to me.

For instance, it has a great set of built-in types with useful operators. You can do date math, array stuff, calculation using precise numbers (numeric), string manipulation, and all that stuff that developers just expect to be able to do in any language. If you can do it in the application, great, but sometimes you are joining based on some condition that requires a little manipulation.

They also do stuff like allowing you to add fields as an O(1) operation without even stopping the application (it requires a table lock, but that should only cause a very short delay). Or writing functions in whatever language you want.

At my old DBA job, one of the things I did early on was write a simple function in perl that fetched some LDAP data and returned the results as a table in postgresql. Now I could join application data against network user data and whip out an ad-hoc report for someone in 10 minutes (which I did on numerous occasions, usually when they weren't expecting the results for at least a day). The developers were impressed at how simple it was, and I could tell they were imagining all the interesting possibilities.

The thing with postgresql is that you, as a developer, never have to leave your developer mindset. You don't have to think of the database as some magical box with a tiny hole where data can go in with "INSERT" and out with "SELECT". With postgresql, if you run into a problem, you can use all of your creativity to solve it, more like a UNIX admin with perl. Postgres is a solid database system, but it gives you a lot of tools to do pretty much whatever you want.

Re:So why

[InverseParadox]

And since you are using MySQL all your referential management is done in code (phone table should have person's id column as a foreign key from persons table, for instance).

...are you saying that MySQL doesn't support foreign key constraints?

News to me; I created a database with about as many of them as I have tables just a couple of months ago, and mysql 5.0.3.2 accepted that just fine.

If that's not what you're saying, I'm not sure what you are trying to get at.

Re:So why

[Sxooter]

MySQL definitely supports foreign keys. Just make sure you're not accidentally using a myisam table, and don't use column level reference defs, cause both will result in a silent ignoring of what you asked it to do.

Wish there was a way to tell it to only use certain table types and throw errors when things go wrong though.

Re:So why

[Sxooter]

But it really depends on what part of the work you're talking about as to whether or not the db is the better choice to do it. It's also not uncommon to see things done on the app server cost as much, if not more, in terms of the db server overhead, because they have to move more data out and back into the db to do what the db can do locally. Imagine running full text searches by retrieving every row and examining it in the app layer. No way is that gonna be better than letting the db do it.

I've yet to see an app provide data integrity cheaper than the db can do it, and there's also the issue of consistency and race conditions if the app is trying to do it.

OTOH, a lot of business logic is much better suited to being in the app layer. Generally speaking, IO intensive things belong in the DB, CPU intensive things belong in the app layer.

Re:So why

[Anonymous Coward]

Ken, this is God, stop touching your database...

Re:So why

[Sxooter]

I find slony works fine and scales well enough, but you often have to setup a star system. replicate to one slave, that replicates to all the other slaves and does nothing else. Also, slony runs slow on slower hardware, but on bigger 4 to 16 core servers with plenty of IO bandwidth, it runs quite quickly.

And when it stops replicating, there's a reason, usually my mistake, that it did.

Re:So why

[Sxooter]

MySQL was once much faster at lots of small queries. Now that's not so true. It's still faster, but only by a few percent most the time.

I know a lot of developers who had the same attitude you're putting forth, that they don't need complex queries. Then I rewrote their reporting apps which ran for 20 or 30 minutes by pulling in all the data one table at a time and munging it together. The same app, using pg to return the same data but do the work in the db dropped the time down into the sub minute range. As a bonus, the load on the db server went down too.

The type of thing MySQL is good at is content management, where the queries are usually simple and small. for that kind of stuff I can totally understand sticking with it. Like Slashdot!

Re:So why

[ultranova]

I have to say I find pgsql far more flexible than MySQL. And you can't put ACID in the app. Sorry, but whoever told you that works lied to you.

Of course you can. Simply implement it in the client libraries, and have them communicate and coordinate via shared memory to keep track of what data should be shown to the client application. It might be simpler, thought, to separate this functionality to a separate proxy process, which uses the database as a backend. Of course we still won't get the guarantee that data has been logged into permanent storage, but we might be able to solve that problem by writing it to log files on the side, and consulting them on startup. We could even index those logs and satisfy some queries directly from those. And if performance isn't really critical, we could even store all data in indexed flat files and make do without MySQL backend!

You know, I think we might be on to something big here! I think I should patent this "Database Management Proxy".

Re:So why

[CarpetShark]

Yeah, right.

Re:So why

[gullevek]

Honestly. I don't care if MySQL goes off like a Ferrari, but only arrives 1/2 of the time. I need my data 100% secure. And postgresql does this for me. My longest running postgresDB I had on one server was 5 years, went through several major upgrades, and works.

I trust postgresql very much, more than I will ever trust mysql.

And I have schemas, who needs cross db joins ...

Re:So why

[gullevek]

I agree. The first time I tried postgresql (was 6.x version) it felt horrible complicated and not as easy as mysql. Much later when I tried it again and used it more, I realized how amazing good postgresql actually is.

Nowadays I only use postgresql and really don't look back on the mysql days. But yes, postgresql needs some time to learn, but once you know it, its a very different thing.

Re:So why

[Carik]

The type of thing MySQL is good at is content management, where the queries are usually simple and small. for that kind of stuff I can totally understand sticking with it. Like Slashdot!

Precisely.

And for those of us who've never done anything much out of the realm of content management, MySQL is all we need.

For something substantial... that's where you want Postgres.

Oddly, I found myself spending about an hour in a meeting yesterday trying to convince people to go with Postgres instead of MySQL -- we're building a backend for a database that's going to probably end up being used by 4-12 departments, and needs to reliably store and manipulate data for potentially upwards of 15,000 students. That really seems like a place where reliability counts more than anything. Everyone else decided to go with mysql on the grounds that they know it.

Re:So why

[turbidostato]

"...are you saying that MySQL doesn't support foreign key constraints?"

It does... on innodb tables, not on myisam. Most mysql implementations will create tables using myisam unless explictily told otherwise and just will silently ignore foreign key constraints is such a case.

But that was not the point for this case: the app was using mysql because it was "legacy"; you can bet it is not using foreign keys and it's managing intertable data integrity in code. And then, most implementations need using foreing keys almost as soon as it has more than two tables. What was the use-case in practice for a RBDM without such support (as it was back in the not so distant day) but plain ignorance? Not to say there *can* be a use case for going without referential integrity but just look at data schemas of most apps you can download from, say, freshmeat, take it as a reference for the other bazillions of internal-only apps in use in companies and tell me on straigth face that an abysmal majority of them are not using mysql due to plain ignorance.

Re:So why

[jalefkowit]

does data encapsulation and all the other oop goodies really help you?

Yes. Putting your business logic into objects makes it easier to keep your business logic separate from your presentational logic; failure to keep those two things apart is why PHP developers get knocked for writing "spaghetti code".

And more...

[jadavis]

Upgrade in place is done via pg_migrator.

VACUUM now makes use of a "visibility map", which means that it doesn't need to process old data each time VACUUM is run. If you run VACUUM on a large table, and then immediately run it again, the second run will be instant.

The recursive queries are the SQL standard common table expressions, that is, WITH and WITH RECURSIVE.

The window functions is a great addition, but with PostgreSQL it's even better because you can define your own custom window functions with CREATE FUNCTION.

There are also a huge number of little improvements, like "auto explain" which is a module that can automatically log the "EXPLAIN ANALYZE" output when a query takes a long time. This is a great convenience for DBAs, because you don't have to look at long-running queries in the log and attempt to EXPLAIN ANALYZE them manually.

Re:And more...

[tcopeland]

> Upgrade in place is done via pg_migrator

Outstanding. That was kind of painful when I upgraded RubyForge to PostgreSQL 8.3; looking forward to a much smaller downtime window for the upgrade to 8.4.

Too bad replication didn't make it in there... maybe in 8.5.

Re:And more...

[afidel]

Auto explain sounds like a killer feature, I wish Oracle had that (auto trace is NOT the same).

Re:And more...

[Anonymous Coward]

Apparently replication is the priority for v8.5 development (so says another poster).

Re:And more...

[jadavis]

That was a feature that caught my eye, too, which is why I mentioned it. It seems like a small thing, but it makes life easier.

Not only that, but it allows you to explain nested plans, like those from within functions executed in the outer plan.

cross database joins??

[Foofoobar]

Can I do a cross database join yet? To date this has still been a feature that has yet to be implemented that I can do in just about every other RDBMS.

Re:cross database joins??

[Just Some Guy]

You have an interesting idea of "database". Why not use schemas instead?

Re:cross database joins??

[MagicMerlin]

That's not quite fair. mysql doesn't really have them either. mysql cross database joins are simply working around there lack of support for schemas. Schemas are better in virtually every way...

if you need x database joins in postgres, you can always use dblink of course.

Re:cross database joins??

[Simon (S2)]

Can I do a cross database join yet?

No. They where not implemented in this version, and the workaround is still the one using contrib/dblink, which allows cross-database queries using function calls.
Still, even if I sound like a fanboy, this is a very minor annoyance: PG is the best OSS, Free, Gratis, RDBMS available.

Re:cross database joins??

[Anonymous Coward]

If you're coming from MySQL: What MySQL calls "databases" are called "schemas" in PostgreSQL. MySQL has no equivalent of PostgreSQL's "database".

There is also db-link and dbi-link.

Re:cross database joins??

[Foofoobar]

I use the same definition for 'database' everyone else in the industry uses. What the hell are you talking about 'schema' boy?

Re:cross database joins??

[Sxooter]

This has been explained previously in this thread.

In Postgresql, schemas are equivalent to databases in MySQL. MySQL has no equivalency to PostgreSQL's database really.

Of course, I don't think you're actually looking for an answer, you're just being a mysql fanboi

Re:cross database joins??

[Foofoobar]

actually no. I was merely responding to an obvious TROLL.

So what?

[Anonymous Coward]

Not one of these features is remotely compelling enough to switch an existing, working app from MySQL.

So what? There's *lots* of places where software X is much better than software Y but the cost of migration is higher than the cost of doing nothing.

Re:So what?

[gullevek]

I would give a +100 insightful, but I have no mod points.

Sadly most people forget exactly that. I did one project of transforming an application from mysql to postgres. This was a very small application, but it still took an amazing long time to transform it over.

So most the time I would say, if it works, stick with it.

Oh, hallelujah!

[Just Some Guy]

Deadlocked Query Display
No more log detective work to track down which operations deadlocked; the information is right there.

That alone is worth the upgrade to me. Currently, if you have two deadlocked transactions, it's a pain in the neck to figure out exactly which ones are involved.

Re:Oh, hallelujah!

[Bovius]

Good lord, I didn't see that in the new feature list. Thank you, good sir, for bringing this to our attention. I've spent many frustrating hours trying (and often failing) to track this information down.

Re:Oh, hallelujah!

[Just Some Guy]

We're in the same boat. I had a little script that tried to cobble the information together from a bunch of queries while logged in as admin, but that was so far from ideal that I could hardly stand it.

Thanks for all the good work.

[Futurepower(R)]

Very impressive. Thanks PosgreSQL developers.

Windowing Functions

[ProfFalcon]

OK, the windowing functions are exactly what I was waiting for. RANK and DENSE_RANK are phenomenal.

See the presentation by Hitoshi Harada here: PDF Presentation

Re:Windowing Functions

[mtremsal]

The example in the presentation explains well how stupidly powerful windowing functions are.

What compares to Access on PostgreSQL?

[bogaboga]

What I'd like to say is:

Access is to Microsoft's Jet Engine while {name it>} is to PostgreSQL. By the way I would like an Open Source implementation.

Re:What compares to Access on PostgreSQL?

[mbenzi]

pgAdmin III http://www.pgadmin.org/

Re:What compares to Access on PostgreSQL?

[bogaboga]

Oh really? The last time I checked, I could not implement business logic using this. I will check again.

Re:What compares to Access on PostgreSQL?

[ProfFalcon]

Well, you can use Access against a PostgreSQL database. Other than that, there is Rekall as an option. OpenOffice.org's Base is available as well.

Re:What compares to Access on PostgreSQL?

[mbenzi]

I had thought Access and Base would do this, but had never tried. Thanks for the confirmation.

Re:What compares to Access on PostgreSQL?

[floop]

Access is to PostgreSQL. You can easily use access to query and manipulate data in a pg db. If you searched Access and Postgresql, you'd see there are tons of tutorials around the pair. You can also use OpenOffice.org Calc to do the same thing.

Re:What compares to Access on PostgreSQL?

[digitalunity]

OOo Base does indeed with with PG directly or as an ODBC connection.

I've got to say now though, if you're using Base for creating reports on tables that are large, expect it to run painfully slow, even if the data being used in the report is small. It seems to fetch the entire table from the database, regardless of which fields are needed to compile the report.

Re:What compares to Access on PostgreSQL?

[WuphonsReach]

Eh... OpenOffice Base is still a joke compared to MS-Access.

It works fine, if you're using it against an external data source. But because the ODB file format is basically a ZIP, trying to store anything other then a trivial amount of data in an ODB is going to be a bad bad thing.

And it's easier to import/export data out of MS-Access tables (or to even load/save the data to/from remote databases) then in OOBase. Instead, there's a whole ecosystem of for-pay tools that you have to buy in order to move data around with Open Office.

(There are simply a lot of times where you want to give the user their own copy of data to play with, where you don't have to worry about database connectivity, and everything is contained in a single file. MS-Access serves this purpose well, allowing you GUI access to the data tables, the ability to create ad-hoc queries or reports. Without having to jump through hoops to then export/import. You can even link together disparate data sources in an MS-Access file.)

Now if only I could start using it!

[spiffmastercow]

Unfortunately, my employer is hell-bent on using SQL Server. What's worse, they're hell-bent on not spending any money, which leaves us with a SQL 2000 database running on a server that was "just okay" in 2002 serving ~100 users running CPU intensive reports and performing a few hundred thousand transactions a day..

Re:Now if only I could start using it!

[Sxooter]

You work for idiots, and should really start looking for a better job. Seriously.

Next Version Features

[raftpeople]

In the next version the name PostgreSQL is going to be changed to the easier to say XquLck#7SQL

Re:Next Version Features

[Anonymous Coward]

I'll type very slowly so you can understand it.
Post-Gres-Que-Ell

OTOH, if you were trying to be funny, don't worry, you weren't.

I like this one snippet

[goffster]

" .... This should help users migrating from MySQL. ... "

Because we know they are sure to be coming in droves whether they know it or not. :)

Recursive Performance

[Alethes]

Is there a significant performance difference between WITH RECURSIVE and a recursive function?

General Thoughts

[Anonymous Coward]

Wow the features seem pretty good, but still lacks a couple of things:
    - In place migration tool is still in beta, to be real competitive you need to have a fast in place migration tool (pg_dump for anything over 50GB takes forever)
    - Online replication. Now you mostly have offline filesystem based replication

ANyway great job guys, also the window functions are pretty awesome,

Re:General Thoughts

[jadavis]

In place migration tool is still in beta

Check it in a couple days. As I understand it, it was mostly waiting for 8.4.0 to be released.

Online replication. Now you mostly have offline filesystem based replication

The most common replication schemes in postgresql are probably warm standby (which doesn't currently allow reads on the slave), Slony (not builtin) and londiste (not builtin). All of those are online replication (unless you consider warm standby to be offline). Maybe you already know this, but I am just clarifying.

The next release will prioritize hot standby (same as warm standby but you can read the slave), and sync rep as built-in replication systems.

Re:General Thoughts

[Sxooter]

I've been using Slony for years, and while it's not the simplest nor easiest replication to setup, it works, and it works very well, within it's domain of functionality. Yeah, I look forward to hot standby servers in a year or two, but til then, I guess I'll keep using slony.

Parent is correct

[Just Some Guy]

I don't know why that got modded troll because it's essentially true. A PostgreSQL database is subdivided into schemas, each schema being much like an entire MySQL database. If you have a database named "mycompany" with schemas "financial" and "hr", you could have something like

select
employee.name,
budgetitems.lineitemamount
from
hr.employee,
financial.budgetitems
where
employee.paylevelid = budgetitems.lineitemid

You can have multiple schemas with the same table names and disambiguate them by referring to schema.table instead of just table. In other words, they're like MySQL databases, and some mod owes the parent an apology.

Re:Parent is correct

[javilon]

Thats perfectly fine and well, but can you put two different schemas in two different boxes? no, you canÂt.

Re:Parent is correct

[Just Some Guy]

Thats perfectly fine and well, but can you put two different schemas in two different boxes

First, give us a use case explaining what it is you're actually wanting to do. Second, do db-link and dbi-link (from the GP post) not do exactly that?

Re:Parent is correct

[afidel]

We run into cross database links all the time, from a data consistency perspective it's much better to have one system be the system of record and all others pull from that master server. We even do cross platform links (SQL Server to Oracle) with no problems. Of course db-link and dbi-link seem to fulfill that need just fine. We also have a function where we export a CSV file and an outside vendor uses similar functionality to pull the data in by treating the file as a source table.

Re:Parent is correct

[Qzukk]

Thats perfectly fine and well, but can you put two different schemas in two different boxes? no, you can't.

Depending on what you're trying to achieve with that, you could store the data with partitioning and network file systems (not that I'd risk my data that way). But can you actually do hr.employee.id=job.task.employee on mysql when hr and job are "databases" on different servers?

Anyway, if you really have an external database (that may be somewhere entirely different) there's DBlink and its friend DBI-Link.

Re:Parent is correct

[Sxooter]

You can also cobble together some pretty cool stuff using plproxy and views.

Um...

[Estanislao Mart�nez]

SQL Server has always been a decent database. Going to PostgreSQL would probably be a downgrade. Though if I have to say one thing, it would be this: SQL Server 2005 is a lot better in my experience than 2000.

Re:Um...

[Shados]

Of course. But then again, 2008 is leaps and bounds beyond 2005 too.

2000 was good, but paled compared to some of the more expensive competition, and lacked some "enterprise" features. 2005 was a competitive offering. 2008 is in many ways ahead of the competition. And the dev tools rock :)

Re:Um...

[spiffmastercow]

I've been fighting for 3 years now to get them to move to 2005.. Basically the DBA doesn't want to learn how to use the new admin tools, and he makes up excuses for why 2000 is "better". I point out the flaws in that logic, but since the only audience is corporate execs and salesmen, they prefer a simple answer (from the DBA) to a correct answer from me.

Re:Um...

[afidel]

Simple answer, SQL 2000 is EOL, no support unless you bought an extended hotfix agreement back in Q2 2008.

Re:Um...

[Estanislao Mart�nez]

Give the higher ups a simple answer too: SQL Server 2000 Mainstream Support has ended.

Re:Um...

[rgo]

Why is 2008 better than 2005? I've read some whitepapers but I find it to be almost the same when it comes to userful stuff.

Re:Um...

[Anonymous Coward]

How about a nasty regression bug when optimizing self left joins causing it to table scan and a WITH_INDEX caused it to complete index scan followed by full bookmark lookup. SQL 2000 ran it with same dataset with a much better plan.

Re:Um...

[Shados]

Many more data types, including a datetime type that doesn't suck. A new datatype that acts like it stores files in the database but keeps them in an external folder (that one is probably one of the biggest. This is really a big deal. Much more powerful than rolling up your own solution). Major enhancements of the devtools (native SQL intellisense). ETL and business intelligence stuff got big improvements (ability to use any .NET language in SSIS and better use of multi-core CPU for ETL, enhancements to SSAS, etc). New file formats in reporting services. Much better query planner. All around performance improvements.

The list goes on. I'd say 2005 -> 2008 is a bigger jump than 2000 to 2005. At first glance it isn't, because they didn't rewrite as many parts from scratch (like SSIS and Management Studio), but the new datatypes, enhancements to T-SQL, the souped up business intelligence suite, external file management, and performance improvements are a much bigger leap.

Re:Um...

[xwraith_alpha]

Simple answer, SQL 2000 is EOL, no support unless you bought an extended hotfix agreement back in Q2 2008.

Yep, used this myself. Besides if your DB is in some way incompatible with 2005, just run it in 2000 compatibility mode.

Re:Um...

[cervo]

That's what forced my company to upgrade too. I suggest spiffmastercow mentioned that he is concerned that the company won't get any more support from Microsoft. But the first company I worked for is on 2000 and will stay on 2000 until the end of time. They are a start up and SQL Server 2000 is "good enough" for them. They are too cheap to buy a support contract so it works for them.

ask...

[SiggyRadiation]

...slashdot!

my opinion

[Lord Ender]

SQLite on the low end, Postgres for mid-range apps, and Oracle on the high end.

Where is the niche for MS SQL and MySQL in this picture?

Re:my opinion

[pembo13]

The MS SQL niche is for those that loyal to Microsoft, regardless of cost. For those who will write Microsoft any size check because they are already using all Microsoft's other software, so what's a few more dollars... even though their company just cut staff by a few percent, you can't decide to simply not pay your license fees.

That said, save for what I consider to be a lack of data types, SQL server is better than MySQL.

Re:my opinion

[Anonymous Coward]

Microsoft development shops will prefer Microsoft SQL server as the MS tools and languages integrate best with it. So yes, there will always be a market for MS-SQL.

Additionally, Microsoft SQL Server Reporting Services is being used by alot more companies for BI.

Re:my opinion

[dave562]

The niche for MS SQL comes from all of the developers who have developed apps built on top of it. Most of those apps have been around for longer than a few years. From the point of view of a developer coding a new application from the ground up, it might not make much sense to saddle customers with the cost of MS SQL licenses when something like Postgres could get the job done.

Another issue might come from scalability. MS SQL scales pretty well. Postgres is still waiting into introduce it. Once they introduce it, how long until it is stable?

Re:my opinion

[afidel]

SQL Server enterprise is now significantly cheaper than Oracle Enterprise. Back in 2006 we got Oracle for a price that MS wouldn't match, but Oracle is licensed per core while MS is licensed per socket so as hardware advances the MS solution is now much cheaper. Heck the list price for a quad core box (about all you can buy today) is $50k for Oracle vs $25k for MS. SQL Server 2005/2008 are definitely good for all but the biggest of workloads and support all the normal enterprise features.

Re:my opinion

[Estanislao Mart�nez]

SQLite on the low end, Postgres for mid-range apps, and Oracle on the high end. Where is the niche for MS SQL and MySQL in this picture?

No, it's more like:

• SQLite for single-user application-specific data;
• Postgres for low- to mid-range multiuser OLTP;
• SQL Server for mid- to high-range multiuser OLTP, and for affordable OLAP;
• Oracle for high-range.

SQL Server is better than Postgres, period, and has tons of features that Postgres doesn't.

Re:my opinion

[Sxooter]

"SQL Server is better than Postgres, period, and has tons of features that Postgres doesn't"

[Citation needed]

Re:my opinion

[cervo]

Actually a lot of companies build new apps in SQL Server. It works "Good Enough" for them and they don't need to sacrifice their firstborn sons for an Oracle License. Also in my first company we did some benchmarks with Microsoft SQL Server 2000 VS MySQL VS PostgreSQL around 2003 and in the end SQL Server 2000 ran the fastest. We had MySQL/PostgreSQL on Redhat Linux and SQL Server 2000 on Windows 2000. Maybe at the time we weren't expert MySQL/PosgreSQL tuners, but we also weren't expert SQL Server tuners either...It just worked faster out of the box.

I know a few people who use Oracle as well who prefer SQL Server. I didn't know why because Oracle supposedly was much better, cursors had less of a performance penalty, Oracle also had arrays in PL/SQL (which I have been whining about in SQL Server for a long time). But now that I use Oracle in school I realize it is really a pain to use. PL/SQL is extremely rigid while in SQL Server you can use Transact SQL constructs in any query. Also the Oracle error messages are much more cryptic than those in SQL Server. Performancewise I'm sure Oracle can't be beat, or else companies wouldn't continue to pay their huge licensing fees (although more and more people are changing from Oracle to SQL Server, Sybase, IBM DB2, or the various open source databases). However there are a number of databases that are pretty small (less than 1 GB) with light transaction volume (maybe just some department's system). Personally instead of going with even SQL Server I'd just pick MySQL or PostgreSQL (I am biased towards PostgreSQL because it was designed with ACID compliance much longer than MySQL and many of its features [triggers, stored procedures, etc.] have been around longer than the ones in MySQL).

But for companies with a Microsoft vendor relationship often internal development SQL Server instances are free due to the MSDN or enterprise site license. You only need to pay extra for the production boxes. Still what is "internal" and what is "production" is often stretched and open to interpretation with the bias being on internal. Also if licensing is too expensive and you use the L word and are a giant client often Microsoft is willing to "work with you" to help make it affordable. Still personally if I opened a small business I'd just use PostgreSQL or MySQL to save on licenses. But if you already have MSDN and Microsoft Enterprise Agreements, using SQL Server may not be a huge cost in terms of your overall IT budget....

But anyway overall Microsoft SQL Server is cheaper than some alternatives (like Oracle). It is on the Microsoft Platform which is good for Microsoft shops. There are a lot of great tools included with it. And the Microsoft name gives some people a warm fuzzy feeling. Also as a database goes it is ACID compliant and it is actually pretty stable. I find SQL Server to be a pretty good Microsoft product overall. 2005 added a number of features like extended XML support and support for .NET code running in the database which correct a lot of gripes I had. If windows was as good as SQL Server I would be lining up to get my copy of Windows 7..... But seriously for me Microsoft Office, Visual Studio, and SQL Server are among the best Microsoft products I have ever used. They are too expensive for me to go buying like crazy at home and if I had my own business I'd go with Linux/PostgreSQL probably. But I still say it is pretty good software and I'm not the only one who recognizes that. People will continue to migrate from other DBMS packages to SQL Server as well as tapping into it due to existing vendor relationships with Microsoft.

Re:my opinion

[Estanislao Mart�nez]

Easy example: PostgreSQL doesn't have native materialized views, whereas SQL Server does have a materialized view implementation, which they call "indexed views." SQL Server indexed views are updated automatically on commits to the base tables of the view, so they're never out of date (unlike Oracle materialized views, for which the automatic updates on commit are an optional feature).

There are a bunch of articles online about how to simulate materialized views in PostgreSQL using tables and triggers, so you might argue that with a bunch of extra work, you could simulate most of what SQL Server is doing. However, there's more! SQL Server's query planner is capable of rewriting a query against the base tables to use an indexed view when appropriate. This means that you can, for example, speed up frequent queries that perform costly grouping and aggregation by creating an indexed view that precomputes the aggregate, without changing your query or application at all. This is impossible to reproduce in PostgreSQL; you'd have to change the application query to use the fake materialized view that you worked hard to create.

The list of things like this goes on and on. PostgreSQL is a decent database, especially given the fact that it's free as in speech; none of this is a discredit against it. But it's simply outclassed by SQL Server.

Re:my opinion

[Sxooter]

I've built materialized views following the online tutorial for pgsql. Took me about 1 hour to set them up and have them working. And it's not simulating a materialized view, it IS a materialized view. With the materialized view, pg also uses the indexes on it. And you don't have to change the app, for christ's sake you just put the materialized view in place of the old view. You ever actually use postgres for much?

Next item on your list?

Re:my opinion

[WuphonsReach]

We've already migrated our internal applications away from MS SQL and switched over to PostgreSQL. Once we got up to speed on pgsql's design and security, migration was not that hard.

I want to say that v8.1 was probably the first reasonable version for us with the native Windows executables instead of having to depend on Cygnus.

Mostly, we're tired of worrying about licensing issues, and tired of paying for constant upgrades. A Linux box running pgsql is a heck of a lot less expensive over the long run. (Plus the ability to script things in bash / perl / python / etc is a strong selling point.)

Repeatable SQL

[Anonymous Coward]

One phrase: repeatable SQL.
INSERT IGNORE,
INSERT .. ON DUPLICATE KEY,
ALTER IGNORE TABLE,
etc.
I searched for these features in Postgress, but could not find any of them. Without the means of making SQL repeatable, a database is completely useless to me.

Off course the fact that such probably must be done with programming on the database server (what could possibly go wrong?) makes it even worse.

Re:Repeatable SQL

[rtaylor]

Take a look at the more general SAVEPOINT feature. They can be thought of as sub-transactions.

Any transactional statement may have the exception caught and effects rolled back within the parent transaction but it will accommodate complex logic:

BEGIN;

SAVEPOINT trying_complex_action;
DELETE ...
UPDATE ...
DELETE ...
INSERT ...
-- INSERT threw exception. Catch it!
-- Determine this is the type (say unique value exception)
-- we don't care about and get rid of this work
-- continuing with the outer transaction.
ROLLBACK TO SAVEPOINT trying_complex_action;

I regularly use this to ignore unique value violations but still pass something like a bad date format upstream to the application. You can opt to rollback on all errors if you choose.

Re:Repeatable SQL

[jadavis]

One phrase: repeatable SQL.

How about: "insert ... select ... where not in (...)"?

Re:Repeatable SQL

[Sxooter]

Actually you kinda have it backwards on "what could go wrong". PostgreSQL has a more unix like philosophy, in that it gives you lots of small sharp tools you can use to build a solution to any problem. MySQL, instead of providing these tools, builds a custom but non-standard SQL answer to each and every problem, that mostly works for most people, and when it doesn't oh well, that's what you get.

begin;
select * from table where id=$a for update ;
-- (check number of rows returned if > 1 then)
update table set yada=$b where id=$a;
-- else
insert into table values ($a,$b);
-- if no errors musta worked
commit;

turn it into a function (pick your favorite language if you don't wanna learn plpgsql) and it's all wrapped up and ready to go. And, if that doesn't do exactly what you want, you can CHANGE IT. Something you can't really do with MySQL without forking the code base.

*sigh*

[Estanislao Mart�nez]

You have given what is, I believe, the most common reason for not switching: MySQL works well enough for what you need so it doesn't make sense to expend additional time and effort (you probably don't have much of the former) to learn something that you will only use for the same purposes. It makes sense.

There are two versions of this argument:

1. The version that applies to a system that already exists, and has been developed with MySQL.
2. The version that applies to a system that has yet to be built.

I can buy the argument in case (1), but not in case (2). In particular, when people say that MySQL works "well enough" for what they need, I simply do not believe them. They are simply not counting the amount of time they've wasted on data integrity issues over the years, because they just don't know better that with a superior RDBMS, those problems could be solved from day one.

Re:*sigh*

[Phroggy]

In particular, when people say that MySQL works "well enough" for what they need, I simply do not believe them. They are simply not counting the amount of time they've wasted on data integrity issues over the years, because they just don't know better that with a superior RDBMS, those problems could be solved from day one.

But I haven't had issues with data integrity. No, I don't have a large database. I simply don't have that much data. If I did, and I had enough users accessing the data that data integrity ever became an issue, then yeah, of course I would want to fix it. That would be a compelling reason to switch, certainly. But my future projects aren't likely to be much bigger than my previous projects, and MySQL has performed well enough in the past that I expect it to work in the future too.

[Sigh]... Still waiting for bulk loading...

[gbsmith]

...comparable to MySQL. I think Postgres kicks MySQL's ass (to the extent that DBMSes have asses) in almost every respect. But MySQL wipes the floor with PG when it comes to bulk loading data with possible unique constraint violations. INSERT IGNORE, INSERT REPLACE, and the mysqlimport CLI command wrapping those statements make life soooooooooo much easier when one has to deal with millions and millions of overlapping rows. The typical workaround offered in the PG community is always a clumsy combination of temp tables, rules, triggers, seances and goat sacrifice, usually ending with the phrase, "See? Simple really!".

I think the addition of convenient bulk loading tools could be a game changer for potential enterprise users, or anyone loading high volumes of data.

Re:[Sigh]... Still waiting for bulk loading...

[dkleinsc]

The way I see your problem, you have either a very bad data set (millions of unique constraint violations) or a bad schema (a field that's marked as unique that shouldn't be). Yes, correcting this is a massive PITA, but PostGres is relatively intolerant of those sorts of faults for a reason. Both the INSERT IGNORE and INSERT REPLACE look to me (from the documentation, I'm not a DBA) like they'd be prone to losing some data in a way that you don't notice. Which for anything mission-critical is really really bad.

Re:[Sigh]... Still waiting for bulk loading...

[Anonymous Coward]

I agree respect INSERT IGNORE as it's just a way to skip proper staging,
Now INSERT REPLACE is useful as is mostly MYSQL version of the UPSERT or MERGE statement.

Anyway in the context that the OP wants to use them, both are a very bad idea.

Re:[Sigh]... Still waiting for bulk loading...

[gbsmith]

While I see your point of view (to an extent), I have to disagree with you on most all points:

1) It only takes one UCV in millions of rows to ruin the load. Also, the data may come from another source, and it may be dirty with UCV when we got it.
2) The field(s) is/are marked UNIQUE - and they are supposed to be. We know this.
3) I whole-heartedly agree with PG protecting the table from violations and faults, but I am telling PG ***exactly*** how to handle the fault. Either:
  a) Keep the old and IGNORE the new
  b) REPLACE the old with the new or
  c) INSERT All or nothing - the current default (well... only) behavior

  *) I suppose there is a (d) here: "If the row has a created_at value older than 8 days and the qty_sold is 10 but the completed_flg is false then replace the row else..."
        But then, of course, your really are getting into application logic. (a) - (c) are simply, DB oriented actions.

After any one of these, I expect - heck, I am *demanding* - the constraints to be in full effect. But I would like a choice as to how the faults are handled.

4) If they lose data in a way that is consistent with the constraints and the command (e.g. a row is IGNOREd), that is my fault. I know what I am asking for.

You know, in general, I expect the RDBMS and its rules and constraints to *work for me*; not *me to work for it*. ;-) I want the 999,999 new unique rows in the DB. I *want* the 1 UCV kept out (or at least handled properly). Computer, take care of it! Sure, report back to me what was done... but just do it!

But I will agree that "...losing some data in a way that you don't notice... for anything mission-critical is really really bad." ;-)

Re:[Sigh]... Still waiting for bulk loading...

[HeronBlademaster]

If I were doing what you're describing I'd load the data into a temporary table, clean it up as appropriate, and then load *that* data into the main table.

Re:[Sigh]... Still waiting for bulk loading...

[dkleinsc]

My experience with dealing with large-ish data loads (max of about 500 million records) is that for anything that large you probably want to build a migration app of some kind anyways, in part because of point (d), and in part because you want a consistent state and recoverability in the event of trouble (e.g. server crash). At which point the application can and should be coded to handle the UCVs in some graceful way.

I also was basing my response a bit on the MySQL folks I've come in contact with, who often have a rather loose attitude towards database constraints (which can lead to some rather interesting bugs). Particularly those who come out of the web design end of the LAMP stack often aren't so concerned about details like foreign key constraints, and just want it to (appear to) work. That looseness is something these folks like, because it makes their job seem easier, and thus they tend to avoid DBs like PostGres and Oracle that really enforce the rules.

But then again, I know some DBAs who would fall into your camp on this. What can I say except that large data loads can really suck?

Re:[Sigh]... Still waiting for bulk loading...

[Sxooter]

You should look up both pg_loader (which acts a lot like oracles bulk loader) or pg_bulkloader which does the dirty under the covers trick to just stick data into tables while the db is down and when it comes back up viola, there it is. Both are quite impressive, but have different use cases.

Re:[Sigh]... Still waiting for bulk loading...

[gbsmith]

I thoroughly agree with your second paragraph. And obviously large data loads can suck total ass. :-(

for beginners?

[innocent_white_lamb]

I have what has become a fair-sized database program that I wrote in a version of Basic several years ago. There were good reasons for doing it that way at the time, mostly related to cross-platform requirements, available hardware and a limited set of options at the time, all of which have since become pretty much irrelevant as the years went by. However, the program keeps cranking and has grown and been expanded and added to (by me) into what now amounts to a "management suite" for the business that I wrote it for.

More and more lately, I've been thinking that while this Rube Goldberg contraption is currently working fine, it might be smart to move it onto a real database. So I'm thinking about rewriting the whole thing over the course of time, and the little that I know about Postgresql makes it seem to be just exactly the tool for the job. The whole business runs on Centos Linux now, anyway.

Accordingly, I guess I should get started learning Postgresql. I've been writing programs for 30 years but the only real database I have ever worked with before was dBase and I haven't touched that for years either. Accordingly, I would appreciate recommendations for relevant books, websites, tutorials, whatever.

Re:for beginners?

[DannyO152]

Head First SQL is good. It teaches SQL which is essentially the lingua franca of modern day rdbms. You may be put off by the illustrations and the seemingly non-techie approach, but it does a good job in teaching so you learn it. Download or bookmark the postgresql documentation from www.postgresql.org as an adjunct.

Also, if you haven't, you may want to consider using a different programming language. For instance ruby and java have frameworks, such as ActiveRecord and Hibernate, which free you from a lot of plumbing code. I'm sure other languages have their Object-Relational tools all ready to roll as well.

Re:for beginners?

[hibiki_r]

The PostgreSQL documentation is about as good as I've ever seen in an Open Source product. The manual is typically well written, and it is full of good examples. It makes something like JBoss look line an underdocumented mess.

And if at any point you find that a page of documentation is missing some detail, you can always post it as a comment in that same page, and save the rest of us some grief.

Re:for beginners?

[Alpha830RulZ]

If you're in some strange variant of basic, verify that you can get to Postgres from the language before you get too worked up over it. Pg is a good DB, but the danger of OSS is that niche environments are tougher to support.

That said, if you're not using -any- database at all, MySQL is liable to be a step up as well.

Look into a good dev tool, like Squirrel or Toad.

Re:for beginners?

[Anonymous Coward]

The Purple book:
http://www.amazon.com/exec/obidos/tg/detail/-/0672327562/qid=1127439720/sr=2-1/ref=pd_bbs_b_2_1/103-1309672-0439005?v=glance&s=books

is excellent.

I really wish they improved clustering

[Anonymous Coward]

I really love using postgres over sqlserver or oracle WHERE possible,
but the lack of real (RAC - LIKE) clustering for postgres makes this difficult...
and by clustering I don't mean replication... I mean multiple active nodes (N+1) serving the same databases

Re:I really wish they improved clustering

[Anonymous Coward]

I think we'd all like to see something like RAC. The problem is, it took Oracle something like 10 years to get it to work properly, with hundreds of man-years of effort. The Postgres community has some really smart contributors, but that level of effort is pushing the limits somewhat.

Re:I really wish they improved clustering

[Sxooter]

There are some first runs at such a thing, but they're all alpha level code or have serious restrictions. Look for Postgres-R and Bucardo to see if they can do what you need. Neither are RAC, but then RAC isn't necessarily the best answer all the time either for multi-master, as sometimes you need real shared_nothing clustering.

Re:PostgresSQL

[Informative]

Would you look at that? I tell someone who said something stupid, and his since been modded flamebait, that s/he's a boob. And look, now I'm modded troll.

Here's one with the people with mod points today: "You Boobs".

PostgreSQL is teh awesomz

[noz]

I use PostgreSQL daily and I love it. The window functions are an enormous boon! It's still the best.

We need some distribution happening a la Netezza, Greenplum, etc:

• pgpool-II: old Oracle-style partitioning on a single column with fixed partition values
• GridSQL: stuck in 1.1beta for a long time but promises Teradata-style shared-nothing parallelism

Anyone know better?

Rekall is dead

[Anonymous Coward]

Rekall seems like it was an interesting project but it is either dead or very sick. Its a pity because a decent cross platform RAD database tool seems to be sorely lacking, particularly for small business use.
Perhaps when Kexi is released as part of Koffice 2.1 it will fill provide an alternative to MS Access or at least be an improvement on OO base.

they counted them ...

[itkuil]

postgres=# select count(*) from enhancements;
  count
-------
      293
(1 row)