3 ms·

> Just curious, could you explain what it is that people want from MySQL that they don't get from Postgres? Nothing, but I'd really love the migration story to

> Just curious, could you explain what it is that people want from MySQL that they don't get from Postgres? Nothing, but I'd really love the migration story to be much nicer. The only thing stopping me is a few hundred queries that will need to be rewritten to conform to the Postgres way. There's a few things that Postgres could offer to make the transition a bit easier: - Improve mysqlcompat so that it's a really first class implementation - Offer a configuration package that helps with a lot of annoying differences like booleans values not printing as 0/1 - Offer some MySQL style syntax sugar, like ON DUPLICATE KEY UPDATE, backticks for field names - Offer a case insensitive collation for text fields or build something like citext into the core - Supporting TINYINT and UNSIGNED numeric types would be useful - I like the mysql date handling syntax... I realise that many of these things have perfectly good workarounds available, but it would be much nicer if I didn't have to test as much stuff to confirm it still works.

jcampbell1 14y ago
I really miss "REPLACE INTO". Upserts are a complete mess on postgres. It requires 3-5 queries to get the same behavior.
- viraptor 14y ago
  Maybe I'm missing something, but doesn't it do the same as `IF EXISTS(SELECT ...) THEN UPDATE ... ELSE INSERT ... END`, so 2 queries actually executed? What cases does it not cover?
  - fdr 14y ago
    This is a procedural function, which is a pain in the butt, and slow. MERGE support has been a want-to-have for a long time. Unfortunately Postgres is stuck between the complex but useful behavior of implementing MERGE (without destroying concurrency) and the simpler and still-useful MySQL extension "OR REPLACE". Although it seems like some people have floated the idea of going with the simpler non-standard option without being shot down, it seems like the people interested in doing the work are most interested in implementing the complex and more featureful standardized option, and it's rather difficult, so there is no MERGE yet.

jcampbell1 14y ago

I really miss "REPLACE INTO". Upserts are a complete mess on postgres. It requires 3-5 queries to get the same behavior.

viraptor 14y ago
Maybe I'm missing something, but doesn't it do the same as `IF EXISTS(SELECT ...) THEN UPDATE ... ELSE INSERT ... END`, so 2 queries actually executed? What cases does it not cover?
- fdr 14y ago
  This is a procedural function, which is a pain in the butt, and slow. MERGE support has been a want-to-have for a long time. Unfortunately Postgres is stuck between the complex but useful behavior of implementing MERGE (without destroying concurrency) and the simpler and still-useful MySQL extension "OR REPLACE". Although it seems like some people have floated the idea of going with the simpler non-standard option without being shot down, it seems like the people interested in doing the work are most interested in implementing the complex and more featureful standardized option, and it's rather difficult, so there is no MERGE yet.