such a mysql compatibilty mode seems extremely unlikely. i wouldn't claim that postgresql is strictly ansi, it has a number of incompatibilities, but it tries hard to be ansi and new stuff seems to be well vetted against ansi standards. "mysql compatibility" mode would be a sharp change, and in particular, there are things in mysql that you really wouldn't want to be compatible with (e.g. the behavior with respect to numeric overflows; postgresql raises exceptions while in many cases, mysql silently truncates.)
it did happen at about the same time as the libs converted from LGPL to GPL. a positive correlation doesn't prove causality, but it is an interesting coincidence.
the library licensing change is fairly significant, and a reason why many distributions of linux and *bsd haven't moved to mysql 4.x -- a commercial user of such a distribution might easily get into troube due to lack of awareness of the nature of mysql licensing.
i remember the GPL/commercial software debate from more than a decade ago when i was working in a group at GE R and D; we were starting to migrate a C++ application from the AT&T C++ comnpiler to GNU, and the GPL was very much on our minds. the LGPL came into being specifically to address the library problem, and this mysql license change seems like a substantial step backwards. in other words, we've seen this movie before, only now it's running in reverse.
those limits are pretty much gone now. postgresql has made substantial strides through 7.x on to 8.0
i'm doing a lot of informix work at my new contract gig. informix has a reputation as one of the very best of the big commercial systems, and it is quite good, but i do find myself missing things about postgresql that i think are better and some are feature issues, and some are simply better docs.) point being that many in the postgresql community don't find the mysql comparisons interesting, they want to be benchmarked against the oracles, informixes, and db/2s of the world -- and with each passing release, this comparison becomes more and more valid.
nothing is wrong with that default. for small shops, it's perfectly reasonable.
For very large shops, with serious security concerns, you probably don't want to have to create local user accounts for many of the valid database users, as they're not supposed to have access to the servers running the db at all.
IBM seems to think that they can make good bux on the service business in support of linux deployment.
a lot of people don't get the service model, but it's looking like service may become the wave of the future, given the advances of the open source movement.
mysql's problem is that they took $19M+ in investor money, and now they have to create a business model to support paying that investment back. in my experience, obtaining funding for a service oriented business can be pretty damned difficult. obviously their investors want them to sell licenses.
this correct, but deserves to be elaborated on. postgresql users are orthoganal to OS users, and are created using either the createuser command from the shell or 'create user' from sql. however, in cases where postgresql usernames correspond to OS usernames, it is a viable authentication option to treat them as the same. it is also a perfectly viable option to ignore the similarity entirely.
Slashdot Mirror
such a mysql compatibilty mode seems extremely unlikely. i wouldn't claim that postgresql is strictly ansi, it has a number of incompatibilities, but it tries hard to be ansi and new stuff seems to be well vetted against ansi standards. "mysql compatibility" mode would be a sharp change, and in particular, there are things in mysql that you really wouldn't want to be compatible with (e.g. the behavior with respect to numeric overflows; postgresql raises exceptions while in many cases, mysql silently truncates.)
the library licensing change is fairly significant, and a reason why many distributions of linux and *bsd haven't moved to mysql 4.x -- a commercial user of such a distribution might easily get into troube due to lack of awareness of the nature of mysql licensing.
i remember the GPL/commercial software debate from more than a decade ago when i was working in a group at GE R and D; we were starting to migrate a C++ application from the AT&T C++ comnpiler to GNU, and the GPL was very much on our minds. the LGPL came into being specifically to address the library problem, and this mysql license change seems like a substantial step backwards. in other words, we've seen this movie before, only now it's running in reverse.
i'm doing a lot of informix work at my new contract gig. informix has a reputation as one of the very best of the big commercial systems, and it is quite good, but i do find myself missing things about postgresql that i think are better and some are feature issues, and some are simply better docs.) point being that many in the postgresql community don't find the mysql comparisons interesting, they want to be benchmarked against the oracles, informixes, and db/2s of the world -- and with each passing release, this comparison becomes more and more valid.
For very large shops, with serious security concerns, you probably don't want to have to create local user accounts for many of the valid database users, as they're not supposed to have access to the servers running the db at all.
IBM seems to think that they can make good bux on the service business in support of linux deployment. a lot of people don't get the service model, but it's looking like service may become the wave of the future, given the advances of the open source movement.
mysql's problem is that they took $19M+ in investor money, and now they have to create a business model to support paying that investment back. in my experience, obtaining funding for a service oriented business can be pretty damned difficult. obviously their investors want them to sell licenses.
this correct, but deserves to be elaborated on. postgresql users are orthoganal to OS users, and are created using either the createuser command from the shell or 'create user' from sql. however, in cases where postgresql usernames correspond to OS usernames, it is a viable authentication option to treat them as the same. it is also a perfectly viable option to ignore the similarity entirely.