Prev: Visual Studio 2005, C-language function - avoiding hacks?
Next: [HACKERS] Core dump running PL/Perl installcheck with bleadperl [PATCH]
From: Tom Lane on 8 Mar 2010 15:25 "Kevin Grittner" <Kevin.Grittner(a)wicourts.gov> 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 evidence that there's at least willingness to consider such things. (OTOH I believe that item has been there for quite a long time, without any action being taken.) > I do know that some of the requests were to support behavior we > would consider incorrect (like the non-deterministic results from an > underspecified GROUP BY); not only do we not want to go to any > effort to *add* it, but we'd probably be putting in effort to > *eliminate* it if it was present. Should the TODO list "not wanted" > section explicitly list each such feature, so that non-listed > features aren't painted by the same broad brush? 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. 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. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: "Pierre C" on 8 Mar 2010 15:28 > 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" You can frame this and put it on your wall. -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: "Kevin Grittner" on 8 Mar 2010 15:58 Tom Lane <tgl(a)sss.pgh.pa.us> 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 original post are valid possible enhancements, or is there something else to list?: http://archives.postgresql.org/pgsql-hackers/2010-03/msg00257.php -Kevin -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Andrew Dunstan on 8 Mar 2010 16:11 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. We are always open to good ideas, I hope. The really obvious candidate of missing functionality from MySQL hasn't even been mentioned in this thread, AFAIK: some form of insert_or_update. cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Tom Lane on 8 Mar 2010 16:17
"Kevin Grittner" <Kevin.Grittner(a)wicourts.gov> 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 either way about the other items mentioned there. But anyway the GROUP BY business is the only one that seems to come up often enough to justify an explicit "no" listing. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |