Slashdot Mirror

Home > Support > Professional > North America
http://www.postgresql.org/support/professional_sup port_northamerica

PostgreSQL has done far more with far less capital.

Since you probably won't believe me, I invite you to compare the features of each. Visiting each project's web site is a good place to start. Once you see how much further ahead PostgreSQL is technologically than MySQL, consider how they managed to accomplish that with relatively little capital.

One of my criterias for "software healthiness" is how much the community is involved in the development and management of the source code. It is interesting to see that the source code for MySQL is stored in a BitKeeper repository instead of something more community-friendly like CVS or Subversion. A real turn-off for me, at least.

I've seen some guys at LinuxWorld who were offering commercial PostgreSQL support, and was going to post that link here, but I ran across this one from the official FAQ while googling for it and found it too rich to pass up posting.

Anyway, google for 'postgresql support' and you'll find several hits on the first few pages. A few have dorky requirements like buying a license to their rebranded 'distro' of postgresql.

PostgreSQL has done far more with far less capital.

Since you probably won't believe me, I invite you to compare the features of each. Visiting each project's web site is a good place to start. Once you see how much further ahead PostgreSQL is technologically than MySQL, consider how they managed to accomplish that with relatively little capital.

Well, instead of trolling for Postgres, let's mosey on over to the MySQL website and see if we can figure out why someone might want to pay, hrm? Ahh yes, here we go, MySQL Enterprise. Mmm. Let's click that. Iiiinteresting. Says here you get 24x7 web and phone support plus 30 minute emergency response time. Eat that, pgsql-bugs. You also get consultative support from people who spend all day tuning MySQL installations for max performance and reliability. I can't even find the Postgres analogue of that to make fun of. Lots of other goodies too numerous to mention that might be worth paying for.

If you're tossing Wankr 2.1 together in your bedroom then MySQL free, pgsql, or even sqlite is more than enough to meet your needs. If you run a large business that relies on MySQL to actually make some $$, then purchasing support is a rational choice. Especially since TCO is still about an order of magnitude less than competition.

Oracle and PostgreSQL uses MVCC to reduce the problem of locking.
MVCC makes the system a lot more scaleable with a lot of writing going on.
http://searchwarp.com/swa9860.htm
http://www.developer.com/open/article.php/877181
http://www.postgresql.org/docs/8.2/interactive/mvc c.html
http://www.onlamp.com/pub/a/onlamp/2001/05/25/post gresql_mvcc.html

Microsoft SQL Server 2005 also have some support for MVCC, but I haven't read up on that one. Microsoft SQL Server before 2005 did not have it.

You can easily notice the advantage of MVCC when compering MySQL and PostgreSQL. MySQL is fast until it gets a lot of writes and then it get slow until it dies. PostgreSQL have a more stable curve and can handle a lot more load because MVCC make the writes do not lock the reads.

This was a major advantage for Oracle and it probably still is because MS SQL Server 2005 is still a new product. MySQL is also catching up, but slower.

> Look, most of us want a database system we can use for our
> own limited but still important purposes. We don't need a
> lot of enterprise-level crud bogging us down.

So true. I'm running a small database (only 20 million records), and PostgreSQL is more than sufficient. We use it in production, too, and it's quite solid.

Maybe someday when we get up to 100 TB or so we'll think about something else, but by then PostgreSQL will probably be capable of handling that load as well...

Btw. Postgres was a project from Stonebreaker meant to deal with the limitiations of SQL (POST inGRES).

See the history of PostgreSQL.

When the community picked the old, dormant Postgres source code up (no problem due to the BSD licensing), the first that was added (after some debates) was the SQL syntax, hence the name change to PostgreSQL.

Bye egghat.

Now, if we could just deal with the problem of having a key that could relate to any one of several tables in some reasonable way... that's the other problem I keep hitting over and over again.

In other words, distributed foreign keys.. this has been discussed to some length by Chris Date and other people who work with the relational model. It's a pretty basic constraint, yet no SQL database seems to implement it.

A quick Google turns up a hopeful PostgreSQL discussion, but it quickly turns to PostgreSQL's "table inheritance" feature which is a very flawed idea.

I'd love to see this implemented in a mainstream database, I think about 3 out of every 4 apps I've written needed this.

The Emacs command set is mnemonic as well ("mnemonic" here means that keystrokes are designed to be easy to remember). The basic Emacs commands exist on several logical levels.

There's the character level ("C-f"orward, "C-b"ackward), and line level ("C-p"revious line, "C-n"ext line, "C-e"nd of line, "C-a" beginning of line, can't use C-b you see, so might as well use the start of the alphabet). That's when you think of text as rows and columns of characters.

If you think of text as words and paragraphs, then you replace "C"ontrol with "M"eta (which is the Alt key on modern keyboards). "M-f"orward word, "M-b"ackward word, and so on, at least in fundamental mode.

> Well, there is one thing, Falcon compresses data while Postgresql doesn't. can't help wondering what this will do to performance.

This is actually not true. If you have a variable length column in Postgres and insert data that exceeds 2K in size, it will automatically be compressed by Postgres using a simple LZ compression algorithm. This has been the case since Postgres 8.0. You have to specifically disable this feature if you don't want to use it.

http://www.postgresql.org/docs/8.0/static/storage- toast.html

Falcon looks to be the long-awaited open source storage engine that may become the primary choice for MySQL, and along the way offer some innovation and performance improvements over current alternatives.

Come on. Give me PostgreSQL any day. After fiddling with MySQL at work for a few custom developments (both versions 4 and 5.0.2) i'm ready for anything else. Gave PSGSQL a shot at home and it runs very nice, with lots of advanced features. Anyone with real-world deploying feedback to share?

I've sent the email below to the address mentioned in the trailer of the page:

Hi!

Some minor points:

Large objects:

your page suggests that PostgreSQL does not support large object the
way mysql does. In reality it has been supporting large rows for years
now. It has the TEXT datatype and the BYTEA datatypes to store texts
and binary columns without limits. (Well, both mysql and postgresql do
have huge limits on rowsize)

SQL conformance:

http://www.postgresql.org/docs/8.0/interactive/fea tures.html shows the
details of the SQL conformance for PostgreSQL 8.0, and is (c) 2005,
guess this was available when you researched your comparision.

It especially does not do a subset of SQL 92/99, it's rather compliant
to SQL 2003. Certainly more so than say mysql, which has been slowly
adding SQL support, as you say yourself; notice that Mysql AB in their
sales documentation don't claim any SQL conformance,

PostgreSQL does allow selecting data over different databases via
dblink, but it's a kludge. OTOH, mysql optimization papers still claim
denormalisation as a solution to the fact that MySQL5 only has Nested
Loop as an executation strategy for joins. Furthermore, subselects are
always materialized.

Speed:

I question your blanket statement that MySQL is very fast on complex
queries. As noted above, it's very sensitive to the way a query is
formulated, and has basically only the most primitive execution
strategies for joins and subselects. Complex queries DO involve
usually both of these constructs.
You also mention the problem of forking backends for startup speed
problems. I'd like to point out that the classical solution to that is
to use a connection pool either in your app (as e.g. PHP provides), or
use pgpool.

Stability:

Anecdotal evidence. Fact is that mysql crashed data this month in the
office, and I've had deployed Postgres95 about a decade ago, and never
lost data. Fact is, that MySQL is offering many options where the
application can decide to have an unstable/unsafe DB setup (by
choosing e.g. MyISAM storage), while the same "performance
optimizations" for PostgreSQL are only available via the server
config. OTOH, PostgreSQL has only just now become stable enough on
64bit platforms to consider productive usage.

Special Serverside features:

You seem to miss the wealth of features that PostgreSQL provides. E.g.
it is one of the most flexible DBs to support updateable/insertable
views. Addtionally, it supports vertical table partitioning, etc.

National Language support:

PG can set the language per database and cluster. Actually, it can
only set the encoding while creating the database:

createdb -E UTF8 testdb
createdb -E SQL_ASCII testdb

Hopefully you can update your comparision, don't hesitate to ask if
you have any questions.

yacc

Follows standards, like UNIX follows POSIX.

Uhm...yeah.

http://www.postgresql.org/docs/8.0/static/sql-synt ax.html - see 4.1.2.2, 4.1.5, etc. Sure, they follow standards when they feel like it.

Also, let's not forget the infamous "case-sensitivity in our table names is not a bug, it's a feature!"

Well, if you can argue that, then "missing foreign key constraints is a feature, not a bug!"

i was using pgsql 8.x back in 2005 - so it existed. they just cherry picked versions to get the result they wanted. postgresql.org linked to a new study where both current versions (at the time, and it was recent - pgsql is 8.2 now) of mysql and postgresql were put throught the paces... http://www.postgresql.org/about/news.691

Yep, it does.

> So, we run a full vacuum and reindex
> of our tables nightly through cron.

I've found that just enabling autovacuum seems to keep things in order. And you can tweak it for individual tables if you're so inclined.

actually , this is how you pronounce it : http://www.postgresql.org/files/postgresql.mp3

MySQL speed will really depend on the database engine you use (MyISAM or InnoDB do not perform the same!). PostgreSQL performance is pretty much consistent across platforms.

On the HA side, PostgreSQL has maybe less options: Slony/I (http://gborg.postgresql.org/project/slony1/) for master/slave or Sequoia (http://sequoia.continuent.org/) for multi-master.
MySQL offers MySQL replication (http://dev.mysql.com/doc/refman/5.0/en/replicatio n.html) for master/slave, MySQL cluster (http://dev.mysql.com/doc/refman/5.0/en/mysql-clus ter.html) for those who want to switch to a new storage engine (NDB) or Sequoia (URL:http://sequoia.continuent.org/) for multi-master with transparent failover.

Ruby for Rails by David A. Black.

And, for the love of god, go with Postgres rather than mysql.

It depends on your task. If you are building small to medium-sized web-applications, I would recommend Seaside. For larger projects, there are things like GNUstepWeb and Struts. If you want something slow that doesn't scale well, but is 100% buzzword-compliant, then there's Ruby on Rails. If you want to re-use existing ASP.NET code then you could try Mono.

For many needs, Apache is not a good choice. I personally prefer Lighttpd, which is lighter, faster, and easier to configure. It has nice FastCGI integration, so you can use it with most frameworks.

As for databases, I still haven't found a good reason to use MySQL. If you need a real database, I'd go with PostgreSQL, which is more standards compliant than MySQL, and faster for complex queries. If you want something slightly more structured than a flat file, then try SQLite, which is simple, lightweight, and faster than MySQL for simple queries.

Sun Microsystems: Sun Microsystems provides uptime support, including 24x7 enterprise support, for PostgreSQL 8.1 and above running on Solaris 10.
Hours: 24/7. Number of employees: 30,000 world wide

Fujitsu: Fujitsu provides a full range of value-added services to PostgreSQL business-users including support, training, migration services, consulting, hosting, performance optimisation and system integration.
Hours: 24/7. Number of employees: 150,000 world wide

EnterpriseDB Corporation EnterpriseDB Advanced Server is an enterprise-class relational database management system based on PostgreSQL, the world's most advanced open source database.
Hours: 24/7

Command Prompt, Inc: Command Prompt, Inc. is the oldest and largest dedicated PostgreSQL services company in North America. With over 10 years of profitable debt free operation.
Hours: 24/7

It is several others. Botrh large and small with different specialities. There is a partial list on the PostgreSQL website:
http://www.postgresql.org/support/professional_sup port

This says otherwise.

Guys, it's time to fork MySQL.

...or switch to the excellent Postgres which is more open and a more complete SQL implementation than MySQL anyway.

Expect to see more things like this happening as the IT landscape undergoes it's coming changes.

Loudly drop support for MySQL. Here are two excellent alternatives:

PostgreSQL
Firebird

Still, Debian provides good MySQL packages. Use them instead. If you need support, I'm sure you could find someone to provide it for you.

I'm sure you could cope without, but it seems like this is actually included in some shape or form.. The release notes mention:

Aggregate-function improvements, including multiple-input aggregates and SQL:2003 statistical functions

Binary Large OBjects (BLOBs) are table columns with individual entries are larger than several thousand bytes (typically, those that span more than one page). BLOBs are part of the ANSI SQL standard, AFAIK, which is why it is surprising you'd never heard of them. They differ from MySQL's 'blob' datatype, which is just a big TEXT field. The design of the database (PostgreSQL, DB2, Oracle, T-SQL/MS SQL, etc.) prevents such objects from being stored in the same method that other objects are stored, either because the SQL standard defines maximum sizes for fields or because the physical structure of the database makes it impractical or unreasonable. In the case of PostgreSQL, the objects are internally stored in different tables with different physical files, although that is not seen by the DB developer at all. They're typically used for storing pictures and documents in the DBMS when you cannot or do not wish to use the file system instead, or for literally storing large binary data. it also supports data streaming, AFAIK.

Table inheritance is like a reverse VIEW, and was defined in SQL:1999. Given table A and table B, let's say table B inherits from table A. Table B will then have all the fields from table A plus it's own. PostgreSQL also supports multiple inheritance. It's standard SQL, but it's very weird, IMO. It has some pretty specific uses, like being able to essentially have indexed VIEWs and such, or making a permanent JOINed table.
http://www.postgresql.org/docs/8.2/interactive/ddl -inherit.html

As far as schema changes, the argument goes like this: replication is only necessary on productions systems. Schema on production systems should be static. If you're changing your schema, you probably did something wrong.

IMX, since about 7.3-7.4 PostgreSQL runs just as fast as MySQL under any significant load. It simply scales a lot better than MySQL seems to.

I will say that if you've just recently switched to PostgreSQL that you should be sure you read the documentation on configuring the server. While the default installation of MySQL is to use as much resources as necessary, PostgreSQL's default install is extremely conservative. By default it only allocated 1 MB (yes, one megabyte) for working memory. If you've got more than 32 MB of RAM, you're probably going to need to edit some config files to see any reasonable performance. Try running a VACUUM VERBOSE to determine how many pages or entries you need in your FSM. That's something that needs to be reconfigured on a production system after it's been in place for some time. If you do strange things like mass DELETEs or TRUNCATE TABLE, you'll also need to VACUUM more often.

The .org root DNS servers run on PostgreSQL, so it's not a problem with the RDBMS itself. Postgre has been repeatedly criticized for being so conservative with the default installation settings. I think they should have some configuration tools (in the Windows installer especially) that helps you to make somewhat more sane configuration settings.

The typical response from PostgreSQL devs on the subject is "yeah, if we turned off fsync on our DB it'd run real fast, too". This is partially why PostgreSQL seems to run slower than MySQL on databases that have lots of INSERT and DELETE queries.

I no longer see any reason to ever use MySQL. It's more popular, but I find PostgreSQL, Firebird, and SQLite cover the range of needs so much better. MySQL is great to learn on, but, well, it's just annoying once you really understand the first things about relational databases.

Bitmap indexes will almost definitely be in 8.3. Gavin Sherry submitted a revised patch for them a few days ago.

I think we'll stick with PostgreSQL for our little database.

While many of these companies (I'm looking at the North America region) may be too small/unknown for your tastes, companies like EnterpriseDB (and Command Prompt) are well established and have some very large clients including Sony Online and Vonage.

If you're a Solaris shop, don't forget that Sun offers PostgreSQL support, and obviously they can handle support for fairly large corporations.

By the way, here is a picture from the latest PostgreSQL developer's conference. There are very few "19 year old kids" in that group.

While many of these companies (I'm looking at the North America region) may be too small/unknown for your tastes, companies like EnterpriseDB (and Command Prompt) are well established and have some very large clients including Sony Online and Vonage.

If you're a Solaris shop, don't forget that Sun offers PostgreSQL support, and obviously they can handle support for fairly large corporations.

By the way, here is a picture from the latest PostgreSQL developer's conference. There are very few "19 year old kids" in that group.

I looked at a couple of the popular ones, installed Awffull and played with it for a bit. But it wasn't immediately
obvious to me that any of the common ones supported aggregating stats across domains / hosts. Eg, I have 10 virtual servers on this
Apache box, give me a sorted list of hits per domain/host. Probably one or more of the popular open-source stats packages
*does* do this, but I didn't feel like spending hours examining different ones and installing them. Since my needs were very basic
I just wrote something of my own.

Since all my domains are ultimately served by a Java webapp running on JBoss (I redirect from Apache to JBoss with mod_jk) I just wrote a servlet filter to write hits to a postgresql database. That's it,one table with the hostname, date-time, user-agent, and a handful of other things I care about. Now, getting the info I need is a simple as a quick sql query with pgadmin III. Although I'm looking at using the Eclipse BIRT stuff for looking at the data, as my next project.

create table a (
  xxx mediumint unsigned primary key,
  yyy mediumint unsigned null references a.xxx );
alter table a modify column xxx bigint unsigned;

• Smalltalk - The original OO language and programming environment
• • The Smalltalk Portal
  • For a bit Free of fun and games
  • Gratis Very Fast - Recommended
  • Gratis non-commercial version of the top-shelf product
  • The online Smalltalk library - gratis
• Ruby - OO in a sane file oriented environment
• • The Ruby Portal
  • Buy the best of the books. Only $25 for a pdf download.
  • The gratis first edition as a WWW site
• SQL - You'll need to store your data somehow
• • PostgreSQL - The Free Relational Database off the top-shelf
  • MySQL - The fast, and most popular, one for Web use
  • Gratis book - PostgreSQL Introduction and Concepts as a WWW site
• C and C++ - Get these downloadable books FAQ & Tutorial.
• • The New C Standard - A huge well written book
  • comp.lang.c FAQ'
  • My own modest contribution

• Smalltalk - The original OO language and programming environment
• • The Smalltalk Portal
  • For a bit Free of fun and games
  • Gratis Very Fast - Recommended
  • Gratis non-commercial version of the top-shelf product
  • The online Smalltalk library - gratis
• Ruby - OO in a sane file oriented environment
• • The Ruby Portal
  • Buy the best of the books. Only $25 for a pdf download.
  • The gratis first edition as a WWW site
• SQL - You'll need to store your data somehow
• • PostgreSQL - The Free Relational Database off the top-shelf
  • MySQL - The fast, and most popular, one for Web use
  • Gratis book - PostgreSQL Introduction and Concepts as a WWW site
• C and C++ - Get these downloadable books FAQ & Tutorial.
• • The New C Standard - A huge well written book
  • comp.lang.c FAQ'
  • My own modest contribution

Wake me up when MythTV doesn't depend on a toy database and starts supporting real databases.

On one foot we have Oracle offering their linux flavor based on Redhat. If Redhat folds they are left with having to pick up where Redhat left off and move forward. I don't think Oracle is ready to put that kind of effort into something they wont actually own.

On the other foot, Redhat could start pushing alternate database solutions such as Postgresql. With commercial solutions available businesses may find that they don't need all of the features Oracle offers which not found in Postgresql.

I'll bet that when push comes to shove, Redhat could take some of Oracle's business.

mysql_query($db, "select * from products where (color = ?) and (price < ?)", $color, $maxprice);

Choosing an OS by cliches and slogans is a horrible way to become a fanboy of any OS.

How about try them and see which meets your needs more closely.
Keeping a spare 10GB partition or two to try whatever OS you're considering is the easiest way to make an informed decision of whatever you feel like experimenting with. I've been a unix user since about '82 - including the BSD derived SunOS and NextSteps in the late 80s. But in practice I've found Linux moving faster and making more right decisions than any of the unixes.
(For example, Linux approached theoretically optimal SW Raid performance sooner than Solaris: http://archives.postgresql.org/pgsql-performance/2 006-09/msg00205.php) and is portable to far more platforms (Cell chips; many cell phones; etc) than BSDs are toaday.

But your needs may be different than mine - I'd strongly recommend just trying them for a few hours instead of reading so much propaganda.

PHP makes "wrong things" easy, and "right things" hard.

Evidence: "addslashes", "register_globals" and "magic quotes".

More evidence: PHP Nuke, phpBB, PDO vs PEAR DB.

Taking his advice on software is like taking a coprophagist's advice on fine dining.

Couldn't be more correct. I've done a little PHP hacking when I'd no other choice--it's to be avoided when possible. For what it was meant for initially, it's not too shabby, but as a general solution it's...lacking.

It's not really surprising that the author of PHP would think that the things PostgreSQL buys you aren't worth it. You know, little things like integrity, reliability and stability. Who needs those? Not anyone writing in PHP, certainly.

Le Voila!

Are you astroturf? Really, such content-free cheerleading is suspicious to me.

To counter you, I have to plug my favorite alternative PostgreSQL.

Enjoy, and let me know if there's anything else we can do.

(don't forget to check out the other things we've created for you over here)

In my experience it's not much harder to support Oracle if you are already supporting Postgres provided that you are using at least Oracle 9 and your apps is well designed to support multiple databases. At work I do some development on a Java-based CMS that has backend support for both Oracle and Postgres. All of the queries are in XML files that the developers call query catalogs. In the code we call queries by name, such as listUsers, and them populate the parameters before executing. Pardon me if this some standard Java technique. I'm still relatively new to Java and haven't seen this before.

Anyway, we have two query catalogs: "sql92" and "oracle". What's nice about the way the system is set up is that we put new SQL queries into the sql92 catalog unless we need to use something Oracle specific (very rare). In that rare case we write the sql92 query and then write an identically named query in the Oracle catalog with the Oracle syntax. When the system is configured to talk to Oracle, it looks into the oracle query catalog first and if it doesn't find the named query there it looks for it in the sql92 catalog. The result is that we can support both databases with minimal duplication. 99% of the queries are in the sql92 catalog. We've found that whenever you want to use an Oracle-ism then applying some thought will usually reveal another way to handle the problem that works in both databases. Example: using case statements instead of Oracle's decode.

Schemas are a different story. The datatypes and details are different enough that we have to keep two copies of the files to create the schema and the schema updates. However, these files aren't changed that much. Also, if you are familiar with Oracle's PL/SQL then Postgres's PL/pgSQL isn't much different.

Because of the way things are abstracted in our app it appears that it would be easy to add support for other databases as needed. It's sure been a breeze to support both Oracle and Postgres.

However, Free Software, and Open Source software for that matter, would have died long ago if Stallman had not been defending it

Right, because projects like these would have never been developed were it not for RMS.

Stallman may have done some things to advance Free Software and Open Source, but to claim he is solely responsible is ludicrous.

On the other hand, if you're using db2 for example you'll probably want to partition (with MDC - available even in free product) on day.

Is there any reason you're not also partitioning the PostgreSQL database, other than to make it look bad in the fictional benchmark? Maybe you can do more advanced partitioning with DB2 or Oracle - don't know, haven't used 'em - but PostgreSQL is certainly capable of the trivial example you mentioned.

Seriously, more like PostgreSQL or FireBird.

The reason magic_quotes_gpc is so horrible, is that it is a FALSE SOLUTION. It doesn't provide any safety net at all -- merely the ILLUSION of a safety net, which encourages programmers to assume they're safe, and be sloppy. That's MUCH WORSE than not providing a safety net at all, and forcing programmers not to be sloppy, without giving them a false sense of security.

MySQL Guide to Security:

Magic Quotes
Given the potential harm that can be caused by SQL injection, PHPs automatic input escape mechanism, magic_quotes_gpc, provides some rudimentary protection. If enabled, magic_ quotes_gpc, or "magic quotes", adds a backslash in front of single-quotes, double-quotes, and other characters that could be used to break out of a value identifier. But, magic quotes is a generic solution that doesnt include all of the characters that require escaping, and the fea- ture isnt always enabled (for reasons outlined in the first chapter). Ultimately, its up to you to implement safeguards to protect against SQL injection.

PostgreSQL: 8.1.4 et. al. Security Release FAQ

Q: Is anyone in particular danger?
A: Applications using Far East encodings (SJIS, BIG5, GBK, GB18030, and UHC) which use ad-hoc methods to "escape" strings going into the database, such as regexes, or PHP3's addslashes() and magic_quotes. Since these bypass database-specific code for safe handling of strings, many such applications will need to be re-written to become secure. (Note that the PHP team deprecated addslashes() and magic_quotes in version 4.0 because of the security risk. Unfortunately, it still appears in a distressing number of freeware PHP applications online.)

The designers of PHP have a long track record of making foolish decisions that competent language designers would have never considered in the first place. Then they make it even worse by coming up with half-assed kludges that try to address the symptoms, but fail to cure the disease, with side-effects that are much worse than the problem they were trying to solve!

For example: PHP originally had only deep structure copy semantics (pass by value of arrays and objects, by deeply copying them instead of passing references): when you pass an array, the ENTIRE deep array is recursively copied, instead of being passed by reference, like in almost every other programming language. So then they half-bake a horrible idea they called "references" into the language to paper over the problem, which are entirely unlike references in any other language (even Perl!), even more confusing, and are notorious for causing many bugs in user code as well as crashing the interpreter itself!

PHP's deep copy semantics were such a bad idea, that many programmers don't even realize it works that way, and don't catch on until it causes bugs and extreme inefficiencies in their code. So to kludge around the problem, PHP merely provides the ILLUSION of a safety net, by mimicking and syntactic appearance and name of references in languages like C++ (which are rigorously designed and well defined in terms of pointers), but PHP's references are totally fucked up, and cause more problems than they solve.

So any C++ programmer who reads or writes PHP code is likely to think something totally different is going on, and be surprized when their code doesn't behave as expected, and the PHP interpreter dumps core. The decisions to make PHP copy semantics and references work the way they do were WRONG. But what was even WORSE was to call that half-baked kludge "references", and make them look identical C++ references, so they totally mislead people into misunderstanding how they work, and making many bugs, crashes and security holes, which otherwise would not hav

• Squeak Toys
• More Squeaking
• Very fast implementation
• For grownups
• The Smalltalk Portal

• Postgresql RDBMS

• Free Smalltalk Library
• PostgreSQL Book