Re: [HACKERS] SQL compatibility reminder: MySQL vs PostgreSQL

"Kevin Grittner" writes: > TODO "not wanted" entry rewritten to address just this one issue. > The other issues raise in the original post are valid possible > enhancements, or is there something else to list?: > http://archives.postgresql.org/pgsql-hackers/2010-03/msg00257.php I'm not too sure e

Re: [HACKERS] SQL compatibility reminder: MySQL vs PostgreSQL

Tom Lane wrote: Yes, I think we should narrowly list things we don't want to do. The current wording reads like "we aren't interested in adopting any MySQL ideas", which I don't think is actually the project consensus, not to mention that it doesn't look good from a PR standpoint. Indeed

Re: [HACKERS] SQL compatibility reminder: MySQL vs PostgreSQL

Tom Lane wrote: > I believe we do have consensus that we aren't interested in > adopting MySQL's nonstandard GROUP BY semantics. I don't recall > what else there might be a definite "no" for. TODO "not wanted" entry rewritten to address just this one issue. The other issues raise in the ori

Re: [HACKERS] SQL compatibility reminder: MySQL vs PostgreSQL

So, if php dev doesn't have time to learn to do things right then we have to find time to learn to do things wrong? seems like a nosense argument to me The best ever reply I got from phpBB guys on I don't remember which question was : "WE DO IT THIS WAY BECAUSE WE WANT TO SUPPORT MYSQL 3.x

Re: [HACKERS] SQL compatibility reminder: MySQL vs PostgreSQL

"Kevin Grittner" writes: > I thought that some of the items on the OP's list were requests to > add an alternative syntax for an existing feature, without a change > in semantics. Did I misunderstand that? If not, is it something we > want to consider? I think the pre-existing TODO item is evid

Re: [HACKERS] SQL compatibility reminder: MySQL vs PostgreSQL

Robert Haas wrote: You do know that SQL is Turing-complete, right? That seems largely irrelevant to the problem at hand. It's not impossible to do syntactic transformations from one Turing-complete langauge to another; if it were, there could be no such thing as a compiler. If we

Re: [HACKERS] SQL compatibility reminder: MySQL vs PostgreSQL

On Mon, Mar 8, 2010 at 12:43 PM, David Fetter wrote: > On Mon, Mar 08, 2010 at 12:18:31PM -0500, Robert Haas wrote: >> On Mon, Mar 8, 2010 at 12:10 PM, David Fetter wrote: >> > On Mon, Mar 08, 2010 at 11:58:20AM -0500, Jaime Casanova wrote: >> >> On Mon, Mar 8, 2010 at 4:17 AM, Pierre C wrote: >

Re: [HACKERS] SQL compatibility reminder: MySQL vs PostgreSQL

On Mon, Mar 08, 2010 at 12:18:31PM -0500, Robert Haas wrote: > On Mon, Mar 8, 2010 at 12:10 PM, David Fetter wrote: > > On Mon, Mar 08, 2010 at 11:58:20AM -0500, Jaime Casanova wrote: > >> On Mon, Mar 8, 2010 at 4:17 AM, Pierre C wrote: > >> > > >> >> My opinion is that PostgreSQL should accept a

Re: [HACKERS] SQL compatibility reminder: MySQL vs PostgreSQL

On Mon, Mar 8, 2010 at 12:10 PM, David Fetter wrote: > On Mon, Mar 08, 2010 at 11:58:20AM -0500, Jaime Casanova wrote: >> On Mon, Mar 8, 2010 at 4:17 AM, Pierre C wrote: >> > >> >> My opinion is that PostgreSQL should accept any MySQL syntax and >> >> return warnings. I believe that we should acc

Re: [HACKERS] SQL compatibility reminder: MySQL vs PostgreSQL

2010/3/9 Jaime Casanova : > On Mon, Mar 8, 2010 at 4:17 AM, Pierre C wrote: >> >>> My opinion is that PostgreSQL should accept any MySQL syntax and return >>> warnings. I believe that we should access even innodb syntax and turn it >>> immediately into PostgreSQL tables. This would allow people wi

Re: [HACKERS] SQL compatibility reminder: MySQL vs PostgreSQL

On Mon, Mar 08, 2010 at 11:58:20AM -0500, Jaime Casanova wrote: > On Mon, Mar 8, 2010 at 4:17 AM, Pierre C wrote: > > > >> My opinion is that PostgreSQL should accept any MySQL syntax and > >> return warnings. I believe that we should access even innodb > >> syntax and turn it immediately into Pos

Re: [HACKERS] SQL compatibility reminder: MySQL vs PostgreSQL

On Mon, Mar 8, 2010 at 4:17 AM, Pierre C wrote: > >> My opinion is that PostgreSQL should accept any MySQL syntax and return >> warnings. I believe that we should access even innodb syntax and turn it >> immediately into PostgreSQL tables. This would allow people with no >> interest in SQL to migr

Re: [HACKERS] SQL compatibility reminder: MySQL vs PostgreSQL

Tom Lane wrote: > I think the new item might be phrased a little too broadly. The > problem with mysql's GROUP BY behavior is not the syntax but the > nonstandard semantics, ie, that it will pick a random result row > when the query is underspecified. I thought that some of the items on the O

Re: [HACKERS] SQL compatibility reminder: MySQL vs PostgreSQL

David Christensen writes: > On Mar 8, 2010, at 9:16 AM, Kevin Grittner wrote: > Wolfgang Wilhelm wrote: >>> Isn*t that a good time to think to put that question into the >>> list of things PostgreSQL doesn*t want to do? >> >> Done. >> >> http://wiki.postgresql.org/wiki/Todo#Features_We_Do_Not_Wa

Re: [HACKERS] SQL compatibility reminder: MySQL vs PostgreSQL

Yes, I've seen quite a few of François's posts around on Drupal. Drupal 7 has an OO query building abstraction layer which _should_ address most of the issues and differences between MySQL, PostgreSQL and SQLite (newly supported in Drupal 7) because each driver can form the query string specifi

Re: [HACKERS] SQL compatibility reminder: MySQL vs PostgreSQL

On Mar 8, 2010, at 9:16 AM, Kevin Grittner wrote: Robert Haas wrote: Wolfgang Wilhelm wrote: Isn*t that a good time to think to put that question into the list of things PostgreSQL doesn*t want to do? Yes. Done. http://wiki.postgresql.org/wiki/Todo#Features_We_Do_Not_Want Does this

Re: [HACKERS] SQL compatibility reminder: MySQL vs PostgreSQL

Robert Haas wrote: > Wolfgang Wilhelm wrote: >> Isn*t that a good time to think to put that question into the >> list of things PostgreSQL doesn*t want to do? > > Yes. Done. http://wiki.postgresql.org/wiki/Todo#Features_We_Do_Not_Want -Kevin -- Sent via pgsql-hackers mailing list (pgsq

Re: [HACKERS] SQL compatibility reminder: MySQL vs PostgreSQL

On Mon, Mar 8, 2010 at 9:48 AM, Wolfgang Wilhelm wrote: > +1 > > Isn´t that a good time to think to put that question into the list of things > PostgreSQL doesn´t want to do? Yes. ...Robert > Von: Andrew Dunstan > François Pérou wrote: >> >> My opinion is that PostgreSQL should accept any MySQ

Re: [HACKERS] SQL compatibility reminder: MySQL vs PostgreSQL

: Samstag, den 6. März 2010, 22:01:06 Uhr Betreff: Re: [HACKERS] SQL compatibility reminder: MySQL vs PostgreSQL François Pérou wrote: > > My opinion is that PostgreSQL should accept any MySQL syntax and return > warnings. I believe that we should access even innodb syntax and turn it >

Re: [HACKERS] SQL compatibility reminder: MySQL vs PostgreSQL

On Mon, Mar 8, 2010 at 4:58 AM, Marko Tiikkaja wrote: > On 2010-03-08 11:47 +0200, Pierre C wrote: >>> As far as I can tell, we already do index skip scans: >> >> This feature is great but I was thinking about something else, like SELECT >> DISTINCT, which currently does a seq scan, even if x is i

Re: [HACKERS] SQL compatibility reminder: MySQL vs PostgreSQL

Oh, this is what I believe MySQL calls "loose index scans". I'm Exactly : http://dev.mysql.com/doc/refman/5.0/en/loose-index-scan.html actually looking into this as we speak, Great ! Will it support the famous "top-n by category" ? but there seems to be a non-trivial amount of work to b

Re: [HACKERS] SQL compatibility reminder: MySQL vs PostgreSQL

On 2010-03-08 11:47 +0200, Pierre C wrote: >> As far as I can tell, we already do index skip scans: > > This feature is great but I was thinking about something else, like SELECT > DISTINCT, which currently does a seq scan, even if x is indexed. > > Here is an example. In both cases it could us

Re: [HACKERS] SQL compatibility reminder: MySQL vs PostgreSQL

As far as I can tell, we already do index skip scans: This feature is great but I was thinking about something else, like SELECT DISTINCT, which currently does a seq scan, even if x is indexed. Here is an example. In both cases it could use the index to skip all non-interesting rows, pulli

Re: [HACKERS] SQL compatibility reminder: MySQL vs PostgreSQL

On 2010-03-08 11:17 +0200, Pierre C wrote: > - index skip scans (well, MySQL doesn't really do index skip scans, but > since it can do index-only scans, it's an approximation) As far as I can tell, we already do index skip scans: => create index foo_a_b_idx on foo(a,b); CREATE INDEX => explain

Re: [HACKERS] SQL compatibility reminder: MySQL vs PostgreSQL

My opinion is that PostgreSQL should accept any MySQL syntax and return warnings. I believe that we should access even innodb syntax and turn it immediately into PostgreSQL tables. This would allow people with no interest in SQL to migrate from MySQL to PostgreSQL without any harm. A solution

Re: [HACKERS] SQL compatibility reminder: MySQL vs PostgreSQL

François Pérou wrote: My opinion is that PostgreSQL should accept any MySQL syntax and return warnings. I believe that we should access even innodb syntax and turn it immediately into PostgreSQL tables. This would allow people with no interest in SQL to migrate from MySQL to PostgreSQL without

Re: [HACKERS] SQL compatibility reminder: MySQL vs PostgreSQL

François Pérou wrote: I will continue using PostgreSQL and MySQL user base will continue to grow and one day it will be 1 PostgreSQL user for 1.000 MySQL users. This is life. People have a deep psychological addiction to their believes and ideas. IMHO, PostgreSQL has to be more flexible (in psy

Re: [HACKERS] SQL compatibility reminder: MySQL vs PostgreSQL

Le samedi 06 mars 2010 à 11:01 -0800, Josh Berkus a écrit : > However, "The server is free to return any value from the group" > doesn't > sound like the way we do things, ever. MySQL users might be OK with > queries which return an indeterminate answer; our users are not. > You'll > notice that S

Re: [HACKERS] SQL compatibility reminder: MySQL vs PostgreSQL

On 3/6/10 1:05 AM, Craig Ringer wrote: > Andrew Dunstan wrote: > >> But AIUI that won't be the same as the MySQL behaviour, as documented at >> : >> >>When using this feature, all rows in each group should have the same >>

Re: [HACKERS] SQL compatibility reminder: MySQL vs PostgreSQL

Andrew Dunstan wrote: > But AIUI that won't be the same as the MySQL behaviour, as documented at > : > >When using this feature, all rows in each group should have the same >values for the columns that are ommitted from

Re: [HACKERS] SQL compatibility reminder: MySQL vs PostgreSQL

Le vendredi 05 mars 2010 à 15:40 -0500, Robert Haas a écrit : > having > said that, asking us to make changes that are not based on solid > technical arguments, don't conform to the SQL standard, and most > important that we already clearly said we were not going to make is > not the way to get the

Re: [HACKERS] SQL compatibility reminder: MySQL vs PostgreSQL

francois.pe...@free.fr (François Pérou) writes: > * I am very surprised by the SQL level of Php developers. The example > Drupal developers trying to rewrite SQL queries dynamically adding > DISTINCT clause is just an example. So don't expect them to understand > the difference between MySQL and Po

Re: [HACKERS] SQL compatibility reminder: MySQL vs PostgreSQL

On Fri, Mar 5, 2010 at 3:30 PM, Dave Page wrote: > On Fri, Mar 5, 2010 at 6:25 PM, Robert Haas wrote: >> On Fri, Mar 5, 2010 at 9:55 AM, Dave Page wrote: >>> 2010/3/5 François Pérou : Dear friends, As a reminder, I took part in the development of pgAdmin and I am not looking

Re: [HACKERS] SQL compatibility reminder: MySQL vs PostgreSQL

On Fri, Mar 5, 2010 at 6:25 PM, Robert Haas wrote: > On Fri, Mar 5, 2010 at 9:55 AM, Dave Page wrote: >> 2010/3/5 François Pérou : >>> Dear friends, >>> >>> As a reminder, I took part in the development of pgAdmin and I am not >>> looking for a flame war. >> >> What did you work on François? I ca

Re: [HACKERS] SQL compatibility reminder: MySQL vs PostgreSQL

On Fri, Mar 05, 2010 at 03:10:59PM -0500, Andrew Dunstan wrote: > > > David Fetter wrote: > >On Fri, Mar 05, 2010 at 02:56:23PM +0100, François Pérou wrote: > >>Dear friends, > >> > >>As a reminder, I took part in the development of pgAdmin and I am > >>not looking for a flame war. > > > >You're

Re: [HACKERS] SQL compatibility reminder: MySQL vs PostgreSQL

On Fri, 2010-03-05 at 15:10 -0500, Andrew Dunstan wrote: > > David Fetter wrote: > > On Fri, Mar 05, 2010 at 02:56:23PM +0100, François Pérou wrote: > > > >> Dear friends, > >> > >> As a reminder, I took part in the development of pgAdmin and I am > >> not looking for a flame war. > >> > >

Re: [HACKERS] SQL compatibility reminder: MySQL vs PostgreSQL

David Fetter wrote: On Fri, Mar 05, 2010 at 02:56:23PM +0100, François Pérou wrote: Dear friends, As a reminder, I took part in the development of pgAdmin and I am not looking for a flame war. You're doing a poor job on that latter. You asked before for the PostgreSQL project to "a

Re: [HACKERS] SQL compatibility reminder: MySQL vs PostgreSQL

On Fri, Mar 05, 2010 at 02:56:23PM +0100, François Pérou wrote: > Dear friends, > > As a reminder, I took part in the development of pgAdmin and I am > not looking for a flame war. You're doing a poor job on that latter. You asked before for the PostgreSQL project to "address" the concerns of so

Re: [HACKERS] SQL compatibility reminder: MySQL vs PostgreSQL

On Fri, Mar 5, 2010 at 1:48 PM, Josh Berkus wrote: > Given that Francois seems to return to this list every 3 months with the > exact same set of requests, I think we need to make a habit of ignoring > him the way we used to ignore Al Dev (although I'll comment that Al Dev > was *much* more entert

Re: [HACKERS] SQL compatibility reminder: MySQL vs PostgreSQL

All, Given that Francois seems to return to this list every 3 months with the exact same set of requests, I think we need to make a habit of ignoring him the way we used to ignore Al Dev (although I'll comment that Al Dev was *much* more entertaining). Several members of our community are working

Re: [HACKERS] SQL compatibility reminder: MySQL vs PostgreSQL

On Fri, Mar 5, 2010 at 9:55 AM, Dave Page wrote: > 2010/3/5 François Pérou : >> Dear friends, >> >> As a reminder, I took part in the development of pgAdmin and I am not >> looking for a flame war. > > What did you work on François? I can't find your name in my email > archives or on archives.post

Re: [HACKERS] SQL compatibility reminder: MySQL vs PostgreSQL

On Fri, 2010-03-05 at 12:42 -0500, Robert Haas wrote: > 2010/3/5 François Pérou : > > * I am very surprised by the SQL level of Php developers. The example > > Drupal developers trying to rewrite SQL queries dynamically adding > > DISTINCT clause is just an example. So don't expect them to understa

Re: [HACKERS] SQL compatibility reminder: MySQL vs PostgreSQL

2010/3/5 François Pérou : > > I believe that PostgreSQL should support more MySQLisms in order to BEAT > MySQL. > we BEAT mysql long ago... to make postgres as broken as mysql is not an improve... > Feel free to use my guide on Drupal website. We have to adapt tools to > people, not the converse.

Re: [HACKERS] SQL compatibility reminder: MySQL vs PostgreSQL

2010/3/5 François Pérou : > Thanks for your answers. > > To speak frankly: > > * I wrote the Drupal guide for porting from MySQL to PostgreSQL. > > * I am also the author of remarks about people should use PostgreSQL to > write portable SQL. > > * I am very surprised by the SQL level of Php develop

Re: [HACKERS] SQL compatibility reminder: MySQL vs PostgreSQL

François Pérou wrote: I believe that PostgreSQL should support more MySQLisms in order to BEAT MySQL. Our aim is not to beat MySQL. At least mine is not, and I don't think I'm alone. Many of the MySQLisms you want supported are just broken behaviour, in the view of many people. So you

Re: [HACKERS] SQL compatibility reminder: MySQL vs PostgreSQL

2010/3/5 François Pérou : > * I am very surprised by the SQL level of Php developers. The example > Drupal developers trying to rewrite SQL queries dynamically adding > DISTINCT clause is just an example. So don't expect them to understand > the difference between MySQL and PostgreSQL. It is out of

Re: [HACKERS] SQL compatibility reminder: MySQL vs PostgreSQL

Thanks for your answers. To speak frankly: * I wrote the Drupal guide for porting from MySQL to PostgreSQL. * I am also the author of remarks about people should use PostgreSQL to write portable SQL. * I am very surprised by the SQL level of Php developers. The example Drupal developers tryin

Re: [HACKERS] SQL compatibility reminder: MySQL vs PostgreSQL

2010/3/5 François Pérou : > Dear friends, > > As a reminder, I took part in the development of pgAdmin and I am not > looking for a flame war. > > I would like to point out Drupal community efforts (including myself) to > write down the most frequent problems when porting MySQL from/to > PostgreSQL

Re: [HACKERS] SQL compatibility reminder: MySQL vs PostgreSQL

2010/3/5 François Pérou : > => All non-aggregate fields must be present in the GROUP BY clause > http://drupal.org/node/30 My take is that this is never going to happen unless we are strictly talking about cases where the non-aggregate fields can be unambiguously determined. If we aren't, mys

Re: [HACKERS] SQL compatibility reminder: MySQL vs PostgreSQL

François Pérou wrote: An important pending issue, which goes on and on for years: => All non-aggregate fields must be present in the GROUP BY clause http://drupal.org/node/30 The trouble is that the bottom of this page looks like nonsense to me. The reason that |SELECT COUNT(n

Re: [HACKERS] SQL compatibility reminder: MySQL vs PostgreSQL

2010/3/5 François Pérou : > Dear friends, > > As a reminder, I took part in the development of pgAdmin and I am not > looking for a flame war. What did you work on François? I can't find your name in my email archives or on archives.postgresql.org. -- Dave Page EnterpriseDB UK: http://www.enter

[HACKERS] SQL compatibility reminder: MySQL vs PostgreSQL

Dear friends, As a reminder, I took part in the development of pgAdmin and I am not looking for a flame war. I would like to point out Drupal community efforts (including myself) to write down the most frequent problems when porting MySQL from/to PostgreSQL: The main MySQL/PostgreSQL issues can