Live data from Hacker News

MySQL 8.0 is now generally available

mysqlserverteam.com

61–70 of 105 posts

Re: MySQL 8.0 is now generally available

#61
post #58
post #2

There are some very useful features there, but I can't help but think that MySQL should have had them a long time ago. Is there something MariaDB doesn't have? I'm genuinely curious as I've only really followed PostgreSQL development.

I feel the same way. I've been using and tracking both since the mid to late 90s. I've always wondering why, in a world where PostgreSQL exists, would anyone use MySQL. New releases seems to only slightly close the gap between it and better RDBMSs while retaining quite a few kludges and ambiguities. In the meantime PostgreSQL gets better at the same pace.

I've always wondering why, in a world where PostgreSQL exists, would anyone use MySQL

I am a solid Postgres guy, but MySQL still has a better multi-master replication story. Confident that Postgres will eventually surpass it, possibly even in a later iteration of 10.

Now in a world where Postgres exists why would anyone use MongoDB is a valid question...

Re: MySQL 8.0 is now generally available

#62
post #58
post #2

There are some very useful features there, but I can't help but think that MySQL should have had them a long time ago. Is there something MariaDB doesn't have? I'm genuinely curious as I've only really followed PostgreSQL development.

I feel the same way. I've been using and tracking both since the mid to late 90s. I've always wondering why, in a world where PostgreSQL exists, would anyone use MySQL. New releases seems to only slightly close the gap between it and better RDBMSs while retaining quite a few kludges and ambiguities. In the meantime PostgreSQL gets better at the same pace.

1. LAMP - If you're working with shared hosting, there isn't much of a choice.

2. WordPress.

3. If you need something simple and basic, MySQL is much easier to get up and running.

Re: MySQL 8.0 is now generally available

#63
post #53

I had hoped that the SQL improvements would fix this annoyance, but according to the documentation they did not: create table fib ( a integer, b integer ); insert into fib (a, b) values (1, 0); update fib set a=a+b, b=a; update fib set a=a+b, b=a; update fib set a=a+b, b=a; update fib set a=a+b, b=a; update fib set a=a+b, b=a; select a, b from fib; The correct result according to the SQL standard is a == 8 and b == 5…

I have to say, I wouldn't get your hopes up. If I were MySQL, I wouldn't touch this with a 10 ft pole because it's not likely to really affect somebody's opinion of MySQL enough to switch, but there's going to be at least one person whose code you'll break. Before you can consider SQL compatibility, you have to keep most-popular-version-of-mysql compatibility.

Re: MySQL 8.0 is now generally available

#64
post #35

Earlier quoted context omitted.

People are going to start to think tech companies don't know how to count or something. Jokes aside... I'm wondering the same.

"start to think" ? Microsoft went from Windows 2000 to Windows XP then to Vista and then to 7. If people haven't already been thinking that, this isn't what's going to start it, IMHO.

You forgot (especially you're counting consumer Windows, and 2000 was Server windows) 3.1 -> 95 -> 98 (OK. That was normal) -> ME -> XP -> Vista -> 7 (Which should have been 9 If I counted correctly) -> 8 (another OK count) -> 10 -> ? (I don't remember all the Windows 10 releases)

Re: MySQL 8.0 is now generally available

#65
post #58

Earlier quoted context omitted.

I feel the same way. I've been using and tracking both since the mid to late 90s. I've always wondering why, in a world where PostgreSQL exists, would anyone use MySQL. New releases seems to only slightly close the gap between it and better RDBMSs while retaining quite a few kludges and ambiguities. In the meantime PostgreSQL gets better at the same pace.

1. LAMP - If you're working with shared hosting, there isn't much of a choice. 2. WordPress. 3. If you need something simple and basic, MySQL is much easier to get up and running.

I agree with 1 and 2 but I don't understand 3. Can you please elaborate?

Re: MySQL 8.0 is now generally available

#66
post #53

I had hoped that the SQL improvements would fix this annoyance, but according to the documentation they did not: create table fib ( a integer, b integer ); insert into fib (a, b) values (1, 0); update fib set a=a+b, b=a; update fib set a=a+b, b=a; update fib set a=a+b, b=a; update fib set a=a+b, b=a; update fib set a=a+b, b=a; select a, b from fib; The correct result according to the SQL standard is a == 8 and b == 5…

I have to say, I wouldn't get your hopes up. If I were MySQL, I wouldn't touch this with a 10 ft pole because it's not likely to really affect somebody's opinion of MySQL enough to switch, but there's going to be at least one person whose code you'll break. Before you can consider SQL compatibility, you have to keep most-popular-version-of-mysql compatibility.

No .... this is perfect for a config flag ... you can make it table specific.

Then 4 versions later ... this flag is default

1 more version ... we are now standard compliant

Re: MySQL 8.0 is now generally available

#67
post #5

Woohoo I've been eagerly awaiting this. I use redshift postgres and SQL server at work and looking to migrate from postgres to MySQL for my personal ML projects. Window functions have been a long time coming and I personally can't wait!

There are a lot of postgres fans on HN, would you mind giving some more info on why you want to go from PG to MySQL?

No explanation he could possibly give on HN will prevent him being down voted. Sad but true

Re: MySQL 8.0 is now generally available

#69
post #53

I had hoped that the SQL improvements would fix this annoyance, but according to the documentation they did not: create table fib ( a integer, b integer ); insert into fib (a, b) values (1, 0); update fib set a=a+b, b=a; update fib set a=a+b, b=a; update fib set a=a+b, b=a; update fib set a=a+b, b=a; update fib set a=a+b, b=a; select a, b from fib; The correct result according to the SQL standard is a == 8 and b == 5…

I have to say, I wouldn't get your hopes up. If I were MySQL, I wouldn't touch this with a 10 ft pole because it's not likely to really affect somebody's opinion of MySQL enough to switch, but there's going to be at least one person whose code you'll break. Before you can consider SQL compatibility, you have to keep most-popular-version-of-mysql compatibility.

I agree. If it's desired, use a config setting to make it the default. It was already standard practice in any MySQL database I rolled out to set InnoDB as the default storage engine in the config until it became the shipped default. Like transaction isolation levels, this is something you either set as an administrator for your need, or you let the application setup guide steer you, or you let the application queries specifically set it, if the application needs it. Otherwise,you risk causing real data corruption and loss to existing customers purely for the benefit of being more compliant in your default configuration.

A global and per-session setting is sufficient and more beneficial, IMO, so I think MariaDB took the right approach. If MySQL still doesn't have that setting, well, that's troubling, but I can't say I'm entirely surprised.

Re: MySQL 8.0 is now generally available

#70
post #58
post #2

There are some very useful features there, but I can't help but think that MySQL should have had them a long time ago. Is there something MariaDB doesn't have? I'm genuinely curious as I've only really followed PostgreSQL development.

I feel the same way. I've been using and tracking both since the mid to late 90s. I've always wondering why, in a world where PostgreSQL exists, would anyone use MySQL. New releases seems to only slightly close the gap between it and better RDBMSs while retaining quite a few kludges and ambiguities. In the meantime PostgreSQL gets better at the same pace.

Initial setup of users and permissions in MySQL is vastly simpler that in Postgres, IMO. It may seem like they are close, but in a world where pg_hba.conf ships with a config that easily confuses those that are unaware of Postgres's ident verification, you'll have people get frustrated often, and in a non-easy to diagnose way (at least for people at a familiarity level where they'll run into this).
Post reply on HN