PostgreSQL 7.3 Released

rtaylor writes "Nearly a year's worth of work is out. The new tricks include schema support, prepared queries, dependency tracking, improved privileges, table (record) based functions, improved internationalization support, and a whole slew of other new features, fixes, and performance improvements. Release Email - Download Here - Mirror FTP sites (at bottom)."

Comments

Quick question

[Noose For A Neck]

Did they do anything to improve/add replication support? That seems to be the only real thing that was holding it back from replacing Oracle, as far as I can tell. I know several projects for such a thing were in the works, but they appeared to be very beta.

Re:Quick question

[Khalid]

I don't know about this one, but one the things that were holding it back from replacing Oracle were stored procedures Table function now brings one of the features of stored procedures : the ability to return sets.

Table Functions : Functions returning multiple rows and/or multiple columns are now much easier to use than before. You can call such a "table function" in the SELECT FROM clause, treating its output like a table. Also, PL/pgSQL functions can now return sets.

Drop Column

[farnsworth]

Drop Column
PostgreSQL now supports the ALTER TABLE ... DROP COLUMN functionality.

HURRAY! this has been my biggest annoyance with postgresql since I've started using it. there are workarounds for older versions, but they become arduous when you have a lot of existing data.

this is a *very welcomed* implementation.

I want replication. please.

[Anonymous Coward]

Main feature I've been waiting for replication.

As of a couple of months ago none of the replication options for postgres were any good. Most were unreliable, offered very small features or very hard to set up.

Some looked like they had promise, but were not there.

Please, please, please, add replication to the next release :)

I also wish performance for simple case dbs was faster. eg key value dbs compared to the performance of sleepy cats berkley db.

I'm sure there would be a *lot* of money to be had if someone were to make a good replication system. Possibly releasing it blender styles? Or offering to implement replication for businesses for a fee?

Perhaps one of the postgres groups could ask for donations from some of us users so some developers could work on it full time. I know I could easily convince my boss to cough up for it. Almost any business that relies on postgres could be convinced to chip in I think.

I stand corrected

[ttfkam]

on the concurrancy issue. But once again, what if the update fails halfway through? How do you know which records have been updated and which still need updating?

Going to add and drop a temporary column?

With PostgreSQL (and any other ACID database), that same SQL you wrote is atomic. It either works completely or not at all. No special keywords. No extra steps. It just works.

When it's that easy in PostgreSQL, why would you use MySQL? Note that this is a write operation; Don't assume that MySQL is faster.

Re:I stand corrected

[ttfkam]

Simpler to install? It comes packaged by default in RedHat. For Debian, it's apt-get install postgresql. For a source install, it's ./configure;make;make install. Please explain to me how MySQL is easier.

Simpler? When you need to get a job done, you either have a simple database or a simple app. The amount of logic is the same.

If Joe Newbie doesn't need views, Joe Newbie doesn't have to use views. ...or rules, triggers, explicit transactions, or any of the other things that PostgreSQL can do that MySQL can't. It's not like PostgreSQL mandates the use of every feature.

On the other hand, Joe Newbie shouldn't need to learn about explicit locks, database integrity issues, workarounds because a feature isn't there, etc.

pg_dump is indeed required whenever a minor or major version change happens. That happens once a year or so. It's not like it happens once a week. And of course, that assumes that you upgrade according to PostgreSQL's release schedule. Why you would do that, I have no idea. More likely, you are upgrading/replacing the database box so you would have to dump the data no matter what software you were using.

If the version and hardware configuration are working well, why would you change anything (other than apply patches) by default?

As far as cheap hosting, that's fine. If the hosting company I have to work with has IIS, I'll be using asp won't I? An abundant option isn't necessarily better. It's just more abundant. Going from computer to computer, you're more likely to find Windows 98 than any other operating system. Does that mean it's better? Indeed, sometimes you have to use suboptimal tools to get the job done. This doesn't mean that you have to seek those suboptimal tools out.

If your data doesn't matter as much to you, it doesn't much matter what solution you choose or from whom you get your hosting. If you value your data, why not show it?

If you're hosting your own database machine -- not exactly a rare occurance -- and PostgreSQL and MySQL (and SAP DB and Firebird) cost the same, why on Earth would you choose MySQL?

MySQL is NOT easier to install in my experience. So why choose MySQL?

MySQL is less feature-rich. So why choose MySQL?

MySQL is not significantly faster. Is this why you choose MySQL?

MySQL cannot enforce data integrity.

Need I go on? If crappy hosting is MySQL's only ace in the hole, it's in more dire straights than I had originally thought. As far as I see, the biggest reason to stick with MySQL is that if you've spent too much development time with it (written app logic that the database sould've already handled), it would be too much trouble to switch.

Comment removed

[account_deleted]

Comment removed based on user account deletion