Re: Column headings in csv
Jerry Stuckle <[email protected]> Sat, 23 May 2020 23:02:27 -0400
| Newsgroups | comp.databases.mysql |
|---|---|
| Organization | A noiseless patient Spider |
| Message-ID | <[email protected]> |
On 5/23/2020 9:07 PM, Richard Yates wrote: > On Sat, 23 May 2020 17:19:09 -0700, Richard Yates > <[email protected]> wrote: > >> On Sat, 23 May 2020 19:11:00 -0400, Jerry Stuckle >> <[email protected]> wrote: >> >>> On 5/23/2020 2:14 PM, Richard Yates wrote: >>>> On Sat, 23 May 2020 17:04:43 +0200, Luuk <[email protected]> wrote: >>>> >>>>> On 23-5-2020 15:49, Richard Yates wrote: >>>>>> On Sat, 23 May 2020 10:13:00 +0200, Luuk <[email protected]> wrote: >>>>>> >>>>>>> On 23-5-2020 01:47, Richard Yates wrote: >>>>>>>> On Sun, 02 Feb 2020 13:57:48 +0100, Kees Nuyt <[email protected]> >>>>>>>> wrote: >>>>>>>> >>>>>>> >>>>>>>>> Yeah, you can only ORDER the result of the UNION, not on of its >>>>>>>>> parts. >>>>>>>> >>>>>>>> Actually you can if you order each part and then set a limit. Recently >>>>>>>> I found this out and am using this (in a php application). >>>>>>>> >>>>>>>> (Distribution sites are each assigned to one of several districts. The >>>>>>>> query pulls out the ones from one of the districts to list first at >>>>>>>> the top of a dropdown menu, and then lists the remaining ones.) >>>>>>>> >>>>>>>> $distsitesq=" >>>>>>>> (select distsite, name from distsites >>>>>>>> where ID_district=$ID_district >>>>>>>> order by name limit 999) union >>>>>>>> (select distsite, name from distsites >>>>>>>> where ID_district<>$ID_district >>>>>>>> order by name limit 999)"; >>>>>>>> >>>>>>>> 999 is chosen because in this example it is far larger than the >>>>>>>> distsites table will ever be. Setting the limit enforces the ordering >>>>>>>> of each part. >>>>>>>> >>>>>>> This is not right, it might give look like the correct result, but it is >>>>>>> not guaranteed the correct result. >>>>>> >>>>>> It does produce the correct result in my application. How would it not >>>>>> produce that result? >>>>> >>>>> https://dev.mysql.com/doc/refman/8.0/en/union.html >>>>> >>>>> "Use of ORDER BY for individual SELECT statements implies nothing about >>>>> the order in which the rows appear in the final result because UNION by >>>>> default produces an unordered set of rows. " >>>> >>>> Yes, I understand what the manual says but quoting the manual does not >>>> answer my question. I would point out two things: >>>> >>>> 1. Without the LIMITs in the two parts, an error is indeed thrown by >>>> mysql, but with the limits it passes, suggesting that mysql thinks >>>> that the query is proper. >>>> >>>> 2. The manual describes the "default" behavior. It seems that the >>>> default may be overridden in some circumstances, such as the query I >>>> used. That is even the definition of "default". The manual does not >>>> say "always produces an unordered set" >>>> >>>> Nevertheless, the query that I used works. Since you said that the >>>> correct result was not guaranteed, I was asking if you knew in which >>>> circumstances it would not work, or reasons that it would not work. >>>> >>> >>> I agree with Luuk - this isn't a good construct. As for it "working" - >>> I suspect it's just a hole in the SQL parser code. Adding LIMIT to a >>> clause should not change the validity of ORDER. >> >> I am not at all claiming that it is better or even good. And I have >> substituted in Luuk's suggestion (thanks again!) which also showed me >> a clever technique that I can probably use in other places. >> >> But wouldn't a "hole in the parser code" just account for it not >> throwing an error and not explain why it really does work? I tried >> scrambling the order of the table just to see if the fact that it >> worked was just an artifact of a particular order, but it still works. >> No matter what I do I cannot make it not work. >> >> So perhaps, as you say, adding a LIMIT to a clause (in a union) SHOULD >> not change the validity of ORDER in the clause in some hypothetical >> moral domain, but it seems that it actually does do that in unions. >> >> Why not call this an undocumented feature rather than a "hole"? > > Still cannot break it. Did discover that the parentheses around each > part are necessary. > > (select owner, make, model, color from cars > where owner='Jerry' > order by make, model limit 10) > union > (select owner, make, model, color from cars > where owner='Luuk' > order by color limit 10) > union > (select owner, make, model, color from cars > where owner<>'Luuk' and owner<>'Jerry' > order by model limit 10) > > Jerry Audi A3 red > Jerry Audi TT silver > Jerry Ford Fiesta green > Jerry Ford Fiesta blue > Jerry GMC Savannah blue > Jerry GMC Sierra blue > > Luuk GMC Yukon black > Luuk Ford F100 blue > Luuk GMC Savannah blue > Luuk Ford Mustang green > Luuk Ford Fiesta red > > Zor Audi A4 white > TNP Ford Edsel black > So? A hole in the parser code may allow it to work - and it might even work correctly - for now. But that can change at any time. Undocumented behavior is *never* safe. -- ================== Remove the "x" from my email address Jerry Stuckle [email protected] ==================