Re: SQL compatibility reminder: MySQL vs PostgreSQL

From: "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>
To: "David Christensen" <david(at)endpoint(dot)com>, "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "Robert Haas" <robertmhaas(at)gmail(dot)com>, <pgsql-hackers(at)postgresql(dot)org>, "Wolfgang Wilhelm" <wolfgang20121964(at)yahoo(dot)de>
Subject: Re: SQL compatibility reminder: MySQL vs PostgreSQL
Date: 2010-03-08 16:25:41
Message-ID: 4B94D0A5020000250002FA1A@gw.wicourts.gov
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-advocacy pgsql-hackers

Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> 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 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 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?

> I believe what that's actually about is the idea of converting
> things like Oracle's CONNECT BY into SQL-spec constructs. Doing
> so wouldn't break any existing PG-compatible applications, whereas
> messing with the semantics of GROUP BY probably would.

Yeah, my first draft of that was even broader, not naming MySQL in
particular -- but then I remembered that we've made a few
concessions to Oracle compatibility. As far as I can recall,
though, those tend not to involve new syntax, but functions that
aren't required by the standard -- which seems much less invasive
than the OP's requests.

I'm willing to rework, soften, or narrow the entry as needed, and I
certainly would take no offense at anyone else doing so. I was just
trying to get it listed, since there seemed to be some community
consensus on the point.

-Kevin

In response to

Responses

Browse pgsql-advocacy by date

  From Date Subject
Next Message Jaime Casanova 2010-03-08 16:58:20 Re: SQL compatibility reminder: MySQL vs PostgreSQL
Previous Message Tom Lane 2010-03-08 15:59:19 Re: SQL compatibility reminder: MySQL vs PostgreSQL

Browse pgsql-hackers by date

  From Date Subject
Next Message David E. Wheeler 2010-03-08 16:55:29 Re: Safe security
Previous Message Tom Lane 2010-03-08 16:03:27 Re: Safe security