Re: [HACKERS] MySQL Compatibility WAS: 8.5 release timetable, again
Tom Lane wrote: Greg Stark gsst...@mit.edu writes: Actually it always bothered me that we don't have implicit casts from integer-boolean. I can't see any ambiguity or unintentional effects this would cause problems with. Am I missing something? Personally, as an old Pascal-lover, I always thought that C's failure to distinguish between int and boolean was the single biggest design mistake in the language. I'm very glad that SQL doesn't make that mistake, and I don't want to go against the standard to introduce it. Then you should love Python where everything non-empty is regarded True in boolean context ;-) Cheers Tino smime.p7s Description: S/MIME Cryptographic Signature
Re: [HACKERS] MySQL Compatibility WAS: 8.5 release timetable, again
Tom Lane írta: Greg Stark gsst...@mit.edu writes: Actually it always bothered me that we don't have implicit casts from integer-boolean. I can't see any ambiguity or unintentional effects this would cause problems with. Am I missing something? Personally, as an old Pascal-lover, I always thought that C's failure to distinguish between int and boolean was the single biggest design mistake in the language. On the other hand, the first two programming languages I have learnt was Sinclair ZX Spectrum BASIC and Z80 assembly, I welcomed C being so near to assembly... :-) I'm very glad that SQL doesn't make that mistake, and I don't want to go against the standard to introduce it. In that we agree. SQL is not C. Best regards, Zoltán Böszörményi -- Bible has answers for everything. Proof: But let your communication be, Yea, yea; Nay, nay: for whatsoever is more than these cometh of evil. (Matthew 5:37) - basics of digital technology. May your kingdom come - superficial description of plate tectonics -- Zoltán Böszörményi Cybertec Schönig Schönig GmbH http://www.postgresql.at/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] MySQL Compatibility WAS: 8.5 release timetable, again
Le mercredi 26 août 2009 à 15:51 -0700, Josh Berkus a écrit : I doubt this would be an accurate description of all Drupal developers. My opinion was : Before adding replication to PostgreSQL, it would be better to support a basic set of MySQL syntax seems relevant: DELETE FROM table1, table2 FROM table1 INNER JOIN table2 ON ... UPDATE table1, table1 SET table1.foo=1, table2.bar=3 WHERE table1.foo=2 INNER JOIN table2 ..., etc ... There is not much to add to PostgreSQL, but it seems relevant. Otherwise, replicating some MySQL SQL syntax will not work. As you know, people willing to use PostgreSQL replication are possibly already MySQL replication users. So if they test and PostgreSQL fails, this is too bad. Drupal was only an example, I did not mean to criticize all Drupal developers. Just to say they focus on PHP and not SQL. They don't have time to port MySQL code. Besides, they are very nice people. So I apologize for this short (false) focus. Bye, Jean-Michel signature.asc Description: Ceci est une partie de message numériquement signée
Re: [HACKERS] MySQL Compatibility WAS: 8.5 release timetable, again
2009/8/27 Jean-Michel Pouré j...@poure.com: Otherwise, replicating some MySQL SQL syntax will not work. As you know, people willing to use PostgreSQL replication are possibly already MySQL replication users. So if they test and PostgreSQL fails, this is too bad. yeah! but some times the reason MySQL is not failing on those cases is because it's broken... Consider this one: http://archives.postgresql.org/pgsql-general/2005-12/msg00487.php we don't want to copy the bugs nor the bad designs decisions from MySQL, no that everything from MySQL is bad but i would be scary if we start supporting every single piece of code MySQL accepts -- Atentamente, Jaime Casanova Soporte y capacitación de PostgreSQL Asesoría y desarrollo de sistemas Guayaquil - Ecuador Cel. +59387171157 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] MySQL Compatibility WAS: 8.5 release timetable, again
2009/8/27 Jaime Casanova jcasa...@systemguards.com.ec: 2009/8/27 Jean-Michel Pouré j...@poure.com: Otherwise, replicating some MySQL SQL syntax will not work. As you know, people willing to use PostgreSQL replication are possibly already MySQL replication users. So if they test and PostgreSQL fails, this is too bad. yeah! but some times the reason MySQL is not failing on those cases is because it's broken... Consider this one: http://archives.postgresql.org/pgsql-general/2005-12/msg00487.php we don't want to copy the bugs nor the bad designs decisions from MySQL, no that everything from MySQL is bad but i would be scary if we start supporting every single piece of code MySQL accepts And that behavior has changed to be sane in 5.0+, iirc. -- Rob Wultsch wult...@gmail.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] MySQL Compatibility WAS: 8.5 release timetable, again
2009/8/27 Rob Wultsch wult...@gmail.com: And that behavior has changed to be sane in 5.0+, iirc. 5.0.12+ actually... that is stated in the same thread... the point was that if we simply were saying: hey! mysql can interpret this, make postgres do the same then we could end up with a lot of broken stuff... just because mysql users think is wonderful to not have to write sane code... -- Atentamente, Jaime Casanova Soporte y capacitación de PostgreSQL Asesoría y desarrollo de sistemas Guayaquil - Ecuador Cel. +59387171157 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] MySQL Compatibility WAS: 8.5 release timetable, again
Le jeudi 27 août 2009 à 14:27 -0500, Jaime Casanova a écrit : the point was that if we simply were saying: hey! mysql can interpret this, make postgres do the same then we could end up with a lot of broken stuff... just because mysql users think is wonderful to not have to write sane code... Not MySQL in general. Only the subset which helps and seems reasonable. Bye, JM signature.asc Description: Ceci est une partie de message numériquement signée
Re: [HACKERS] MySQL Compatibility WAS: 8.5 release timetable, again
So when you talk about focusing on usablility improvements you mean that priority should be given to supporting MySQL-specific syntax extensions and ensuring that there are no queries where the MySQL optimizer comes up with a more efficient plan than PostgreSQL? Well, I'd be interested in this just because I *always* want to improve the optimizer. I think these cases demonstrate places we could improve our optimizer still further, just as looking for the same cases with Oracle or SQL Server does. Yes. PostgreSQL should be able to run MySQL code quoted here: This is a prerequisite for people to be willing to test and adopt PostgreSQL. People are not willing to debug frameworks like Drupal and port them to PostgreSQL. We are quite alone and lost. First, off, the evidence is against that; people are doing the work to port things. And creating new projects which are based on Postgres. Second, we're not going to support MySQL's *bugs* and *bad design decisions* which is what lazy developers actually want; they want something exactly the same as MySQL, including bugs. If they want that, they can use MySQL. We are not MySQL, and trying to out-MySQL MySQL is stupid, just as it would be to copy Oracle exactly. Now, there are things which MySQL does better which we should fix, because they are real problems for our users who already like PostgreSQL. These include simple replication, upgrade in place, driver maintenance, covering indexes, MERGE, etc. But we'll do these because they make *Postgres* better, not because MySQL has them. -- Josh Berkus PostgreSQL Experts Inc. www.pgexperts.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] MySQL Compatibility WAS: 8.5 release timetable, again
On Wednesday 26 August 2009 12:17:25 pm Josh Berkus wrote: Yes. PostgreSQL should be able to run MySQL code quoted here: This is a prerequisite for people to be willing to test and adopt PostgreSQL. People are not willing to debug frameworks like Drupal and port them to PostgreSQL. We are quite alone and lost. First, off, the evidence is against that; people are doing the work to port things. And creating new projects which are based on Postgres. Yeah the above is pretty much a non starter anymore. We out rank MySQL on several polls in terms of popularity. Our channel is growing whereas the MySQL one is shrinking. Our community isn't splintered and even projects like Drupal are making it a specific point to fix the original mysql centric design. Now, there are things which MySQL does better which we should fix, because they are real problems for our users who already like PostgreSQL. These include simple replication, upgrade in place, driver maintenance, covering indexes, MERGE, etc. But we'll do these because they make *Postgres* better, not because MySQL has them. Agreed. Joshua D. Drake -- PostgreSQL.org Major Contributor Command Prompt, Inc : 503-667-4564 - http://www.commandprompt.com/ Since 1997, Consulting, Development, Support, Training -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] MySQL Compatibility WAS: 8.5 release timetable, again
Second, we're not going to support MySQL's *bugs* and *bad design decisions* which is what lazy developers actually want; they want something exactly the same as MySQL, including bugs. If they want that, they can use MySQL. We are not MySQL, and trying to out-MySQL MySQL is stupid, just as it would be to copy Oracle exactly. I understand what you mean. To tell you how lazy MySQL people are is my last experience in the Drupal world. In short, on my devel server, Drupal previous/next link display SQL script returns 21.000 rows. Of course, it should return only two rows. The 21.000 rows are then processed step by step by a PHP script. I open a bug and one of Drupal core developers answers: Jean-Michel, this is a friendly warning, please change your behavior. This is getting really annoying. In fact, this core developer does not like the way I try to explain how to use databases. I wrote two tutorials: http://drupal.org/node/559302 and http://drupal.org/node/14 The truth is that Drupal core developers do not believe fixing the prev/next link script is important. They don't care for SQL and don't understand the relationship between SQL queries and CPU cycles. Read this page: http://drupal.org/project/prev_next This performance issue was known for several months and these MySQL developers did not even fixed it. Finally, I escalated to the founder of the Drupal community to ask him to integrate a proper SQL Previous/Next script into Drupal. Their last answer: Holy crap jmpoure, this is not how the community works. We don't beg to Dries. Read: http://drupal.org/node/559424 Now, there are things which MySQL does better which we should fix, because they are real problems for our users who already like PostgreSQL. These include simple replication, upgrade in place, driver maintenance, covering indexes, MERGE, etc. But we'll do these because they make *Postgres* better, not because MySQL has them. After reading my story, I hope we can agree that noone is going to port any MySQL code to PostgreSQL ever. This demands too much intellectual efforts. Many people will migrate from DB2 and Oracle to PostgreSQL. But no MySQL developer is going to use PostgreSQL if he needs to modify SQL queries. I don't want to be offensive, but I really believe it. So we should support a minimal set of MySQL SQL instructions. After several years of porting MySQL code to PostrgeSQL, I believe that this limited list is enough: http://drupal.org/node/14 This is quite a straightforward need. Without this list of issues, PostgreSQL may never be able to run popular products developed under MySQL. Think of all commercial and free software projects. The impact of MySQLisms are huge. I can only compare it to Windows vs. GNU/Linux or FreeBSD. This is what comes in mind first. We are not leaving in a perfect world and there no reason to achieve perfectness. So let's support this list, please: http://drupal.org/node/14 Kind regards, Jean-Michel signature.asc Description: Ceci est une partie de message numériquement signée
Re: [HACKERS] MySQL Compatibility WAS: 8.5 release timetable, again
2009/8/26 Jean-Michel Pouré j...@poure.com: After reading my story, I hope we can agree that noone is going to port any MySQL code to PostgreSQL ever. This demands too much intellectual Surely this is a complete overgeneralization... ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] MySQL Compatibility WAS: 8.5 release timetable, again
Jean-Michel Pour? wrote: To tell you how lazy MySQL people are is my last experience in the Drupal world. In short, on my devel server, Drupal previous/next link display SQL script returns 21.000 rows. Yes, we have seen this too. We have always targeted serious database developers, and those wanting to be serious. It is difficult to cater to MySQL eccentricities and maintain a serious database offering. -- Bruce Momjian br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] MySQL Compatibility WAS: 8.5 release timetable, again
Jean-Michel Pouré wrote: We are not leaving in a perfect world and there no reason to achieve perfectness. So let's support this list, please: http://drupal.org/node/14 Have you tried Drupal 7? It's said to have many of these corrected. Maybe you should stop wasting your time with 6.x. -- Alvaro Herrerahttp://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] MySQL Compatibility WAS: 8.5 release timetable, again
2009/8/26 Jean-Michel Pouré j...@poure.com: After reading my story, I hope we can agree that noone is going to port any MySQL code to PostgreSQL ever. This demands too much intellectual efforts. Many people will migrate from DB2 and Oracle to PostgreSQL. But no MySQL developer is going to use PostgreSQL if he needs to modify SQL queries. I don't want to be offensive, but I really believe it. So we should support a minimal set of MySQL SQL instructions. After several years of porting MySQL code to PostrgeSQL, I believe that this limited list is enough: http://drupal.org/node/14 This is quite a straightforward need. Without this list of issues, PostgreSQL may never be able to run popular products developed under MySQL. Think of all commercial and free software projects. The impact of MySQLisms are huge. I can only compare it to Windows vs. GNU/Linux or FreeBSD. This is what comes in mind first. We are not leaving in a perfect world and there no reason to achieve perfectness. So let's support this list, please: http://drupal.org/node/14 I'm starting to see how you rubbed the Drupal people the wrong way.. Most of the items on your list are misdiagnosed problems or are features that we think are bugs in MySQL. You would get further asking questions and for suggestions than you would insisting that you know better and Postgres should change its interface to match MySQL. With your current approach you're likely to get dismissed out of hand, not unlike what I can well believe happened in the Drupal world. That would be unfortunate because I think there are 2 or 3 real improvements hidden in your list. -- greg http://mit.edu/~gsstark/resume.pdf -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] MySQL Compatibility WAS: 8.5 release timetable, again
Le mercredi 26 août 2009 à 22:06 +0100, Greg Stark a écrit : With your current approach you're likely to get dismissed out of hand, not unlike what I can well believe happened in the Drupal world. This is the case. That would be unfortunate because I think there are 2 or 3 real improvements hidden in your list. Then explain I don't have your skills. Thanks. signature.asc Description: Ceci est une partie de message numériquement signée
Re: [HACKERS] MySQL Compatibility WAS: 8.5 release timetable, again
Le mercredi 26 août 2009 à 16:56 -0400, Alvaro Herrera a écrit : Have you tried Drupal 7? It's said to have many of these corrected. Maybe you should stop wasting your time with 6.x. I am running a large community on the Net and people would like to migrate our framework to Drupal. We agreed to. I already assembled 30 modules to develop a complete service. But it does not scale very well as my testings show that queries are slow. I wrote SQL guides to inform the Drupal community. It seems that Drupal developers do not make a relationship between database and CPU time or memory usage. Therefore Drupal PHP cache is filled with SQL queries. At it demands more and more memory. I am probably going to migrate to Drupal 6.x in a few days and I will fix queries by hand in case of problems. This is what happened when we migrated to PhpBB. Bye, Jean-Michel signature.asc Description: Ceci est une partie de message numériquement signée
Re: [HACKERS] MySQL Compatibility WAS: 8.5 release timetable, again
2009/8/26 Jean-Michel Pouré j...@poure.com: Le mercredi 26 août 2009 à 22:06 +0100, Greg Stark a écrit : That would be unfortunate because I think there are 2 or 3 real improvements hidden in your list. Then explain I don't have your skills. What I'm suggesting is that you should take a different direction, both with Drupal and with us. Instead of saying Postgres is wrong because of your analysis, ask why what's going wrong and what the right way to fix it is. So instead of telling people what to do you're asking for their help. People are a lot more friendly when asked for help than when being bossed around. Your list: PostgreSQL and MySQL do not use the same concatenation funtions (D6 only, fixed in D7) Personally I don't see a problem with us adding this to Postgres now that we have variadic functions. I'm not sure why others are so dead-set against it; it seems a lot less burdensome than some of the Oracle compatibility stuff we have. PostgreSQL does CAST implicitely between int and a domain derived from int (unsolved) This is misdiagnosed. It's not clear where the problem lies if there's a problem but it likely has nothing to do with the cast. If you posted with information and asked for help people would suggest things to test to get more information and eventually find the best way to fix it. PostgreSQL does not allow DELETE on JOINS PostgreSQL does not allow UPDATE or DELETE on multiple tables (not solved) These are a open issues. I would like to have better support here but it's a major feature, not just a minor compatibility issue. Again if you posted the queries and asked for suggestions people would help you rewrite the queries. PostgreSQL does not allow mutiple ROW inserts (PostgreSQL 8.2 + only) As you point out this was added to Postgres 3 years ago PostgreSQL does not allow nested ORDER BY I don't think this is something we're interested in doing. The grammar is hard enough to maintain as it is. PostgreSQL does not automatically cast data between BOOLEAN and INT PostgreSQL does not automatically cast data between INT and VARCHAR/CHAR These are things we've gone out of our way to NOT do. At some cost too. Being loose here makes it easy to miss errors in your SQL. PostgreSQL requires all non-aggregated fields to be present in the GROUP BY clause As I explained at length we could do something here but it would be a major feature and it would still not be compatible with MySQL unless you happen to be using it in a particular (common) way. For more general uses you have to use DISTINCT ON. PostgreSQL requires single quotes and not double-quotes There's no way in the world we would switch this. We're an SQL engine and we parse the SQL language which uses quotes in a certain way. If we switched this we would be parsing some other very different language and everything else written in SQL (including, say, internal queries for referential integrity checks or psql tab completion or pg_dump) would break. -- greg http://mit.edu/~gsstark/resume.pdf -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] MySQL Compatibility WAS: 8.5 release timetable, again
2009/8/26 Greg Stark gsst...@mit.edu: PostgreSQL does not automatically cast data between BOOLEAN and INT PostgreSQL does not automatically cast data between INT and VARCHAR/CHAR These are things we've gone out of our way to NOT do. At some cost too. Being loose here makes it easy to miss errors in your SQL. Actually it always bothered me that we don't have implicit casts from integer-boolean. I can't see any ambiguity or unintentional effects this would cause problems with. Am I missing something? -- greg http://mit.edu/~gsstark/resume.pdf -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] MySQL Compatibility WAS: 8.5 release timetable, again
Greg Stark wrote: PostgreSQL and MySQL do not use the same concatenation funtions (D6 only, fixed in D7) Personally I don't see a problem with us adding this to Postgres now that we have variadic functions. I'm not sure why others are so dead-set against it; it seems a lot less burdensome than some of the Oracle compatibility stuff we have. The Oracle functions are there to add functionality that can't be easily performed using ANSI syntax; this is not true of concact() and ||. -- Bruce Momjian br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] MySQL Compatibility WAS: 8.5 release timetable, again
Greg Stark gsst...@mit.edu wrote: Actually it always bothered me that we don't have implicit casts from integer-boolean. I can't see any ambiguity or unintentional effects this would cause problems with. Am I missing something? I'd be at least a little bit concerned about how such automatic casting to boolean might interact with bug #3822: http://archives.postgresql.org/pgsql-bugs/2007-12/msg00145.php -Kevin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] MySQL Compatibility WAS: 8.5 release timetable, again
Jean-Michel, The truth is that Drupal core developers do not believe fixing the prev/next link script is important. They don't care for SQL and don't understand the relationship between SQL queries and CPU cycles. I doubt this would be an accurate description of all Drupal developers. The Drupal developers I've met have been very intelligent; most don't know much about SQL database, but then I know zero JavaScript so we're even. The answer to this is to be educational and not confrontational. And submit patches ... to a current development version and not an old version. After reading my story, I hope we can agree that noone is going to port any MySQL code to PostgreSQL ever. Again, the evidence is against you. So we should support a minimal set of MySQL SQL instructions. In a loadable module, sure. Patches? After several years of porting MySQL code to PostrgeSQL, I believe that this limited list is enough: http://drupal.org/node/14 There's other stuff as well. Also, see the updates people have made to your list. can only compare it to Windows vs. GNU/Linux or FreeBSD. This is what comes in mind first. Well, I don't use Windows either. So that's a pretty weak argument with me ... -- Josh Berkus PostgreSQL Experts Inc. www.pgexperts.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] MySQL Compatibility WAS: 8.5 release timetable, again
Greg Stark gsst...@mit.edu writes: Actually it always bothered me that we don't have implicit casts from integer-boolean. I can't see any ambiguity or unintentional effects this would cause problems with. Am I missing something? Personally, as an old Pascal-lover, I always thought that C's failure to distinguish between int and boolean was the single biggest design mistake in the language. I'm very glad that SQL doesn't make that mistake, and I don't want to go against the standard to introduce it. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] MySQL Compatibility WAS: 8.5 release timetable, again
On Thu, Aug 27, 2009 at 1:24 AM, Tom Lanet...@sss.pgh.pa.us wrote: Greg Stark gsst...@mit.edu writes: Actually it always bothered me that we don't have implicit casts from integer-boolean. I can't see any ambiguity or unintentional effects this would cause problems with. Am I missing something? Personally, as an old Pascal-lover, I always thought that C's failure to distinguish between int and boolean was the single biggest design mistake in the language. I'm very glad that SQL doesn't make that mistake, and I don't want to go against the standard to introduce it. I'm sure I can think of bigger flaws in C than that :) I tend to think SQL has more in common with lisp than either of those, perhaps because of the tinge of functional programming style. But I think you're generalizing my suggestion to the point of building a straw man to say failure to distinguish. You could argue that using a boolean in places where integers are expected could be confusing or dangerous. But using other data types where boolean values are expected is perfectly reasonable and safe -- especially in cases like integer where people do expect it to work and the behaviour is very predictable. -- greg http://mit.edu/~gsstark/resume.pdf -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
