Well well well. I can see this working well for Oracle - they use Java a great deal... and it should be good news for Sun's open source projects like Netbeans - which would, I think, be maintained under Oracle.
I guess it's a little sad to see Sun unable to continue by themselves, but the writing was on the wall and I think Oracle will keep all the Sun products working, but of course the big question is what does this mean for MySQL?
It remains a functional relational database. It has a BSD-style license with a very stable, nearly bug-free (see Coverity) core. It has modular design (you can write procedures in Java, C, C++, T/SQL, R, Python and others. You can get commercial support from a company (EnterpriseDB) that doesn't have a vested interest in moving you to a very expensive alternative.
OMFG, massive fail for MySQL. I thought you were joking, but you aren't!
mysql> create table foo(bar varchar(10)); mysql> insert into foo (bar) values ('abc'); mysql> select * from foo where bar = 'abc'; +------+ | bar | +------+ | abc | +------+ 1 row in set (0.00 sec)
mysql> select * from foo where bar = 'aBC'; +------+ | bar | +------+ | abc | +------+
Imagine an OS where strcmp() was case insensitive, and where it was used to compare hashed passwords when authenticating users. Realize that base64 is no
Have fun auditing your MySQL-based webapps to make sure that none of them use base64 password encoding coupled with case-insensitive searches!
There is no one-comparison-technique-fits-all. We simply need more powerful and friendly comparing operators that can optionally ignore case, ignore white space, etc. And, without requiring duplicating functions on both sides, such as trim(lower(x)) == trim(lower(y)). That's poor conceptual factoring and hurts readability.
There is no one-comparison-technique-fits-all. We simply need more powerful and friendly comparing operators that can optionally ignore case, ignore white space, etc. And, without requiring duplicating functions on both sides, such as trim(lower(x)) == trim(lower(y)). That's poor conceptual factoring and hurts readability.
I don't see it that way. When I'd revisit that query a year later, I could tell exactly what trim(lower(x)) is doing without memorizing the details of a combinatorially-growing handful of operators (equals, insensitive equals, trim equals, trim insensitive equals, etc.). Add functional indexes (as in PostgreSQL, Oracle, and many others) and you even get excellent performance without the database having to maintain indexes for each of the special operators just in case you might want to use them.
The only person who always got his work done by Friday was Robinson Crusoe.
What about MySQL? (Score:5, Interesting)
Well well well. I can see this working well for Oracle - they use Java a great deal... and it should be good news for Sun's open source projects like Netbeans - which would, I think, be maintained under Oracle.
I guess it's a little sad to see Sun unable to continue by themselves, but the writing was on the wall and I think Oracle will keep all the Sun products working, but of course the big question is what does this mean for MySQL?
Postgres is looking better than ever (Score:5, Informative)
Re: (Score:1)
Re: (Score:1, Insightful)
Their string comparisons are case sensitive.
OMFG, massive fail for MySQL. I thought you were joking, but you aren't!
Imagine an OS where strcmp() was case insensitive, and where it was used to compare hashed passwords when authenticating users. Realize that base64 is no
Re:Postgres is looking better than ever (Score:1)
There is no one-comparison-technique-fits-all. We simply need more powerful and friendly comparing operators that can optionally ignore case, ignore white space, etc. And, without requiring duplicating functions on both sides, such as trim(lower(x)) == trim(lower(y)). That's poor conceptual factoring and hurts readability.
Re: (Score:2)
There is no one-comparison-technique-fits-all. We simply need more powerful and friendly comparing operators that can optionally ignore case, ignore white space, etc. And, without requiring duplicating functions on both sides, such as trim(lower(x)) == trim(lower(y)). That's poor conceptual factoring and hurts readability.
I don't see it that way. When I'd revisit that query a year later, I could tell exactly what trim(lower(x)) is doing without memorizing the details of a combinatorially-growing handful of operators (equals, insensitive equals, trim equals, trim insensitive equals, etc.). Add functional indexes (as in PostgreSQL, Oracle, and many others) and you even get excellent performance without the database having to maintain indexes for each of the special operators just in case you might want to use them.