db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dag H. Wanvik (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (DERBY-6008) Allow ORDER BY and FETCH/OFFSET in set operands
Date Thu, 13 Dec 2012 18:28:13 GMT

    [ https://issues.apache.org/jira/browse/DERBY-6008?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13531276#comment-13531276
] 

Dag H. Wanvik edited comment on DERBY-6008 at 12/13/12 6:26 PM:
----------------------------------------------------------------

Thanks, Bryan! As for tabs, I gave up trying to retain tabs years ago, I try to make my patches
only use blanks for all new code. I know it looks 
awkward when one reads the patch in a tab=8 context, but alas... I set my tab width to 4 in
Emacs before I inspect patches to avoid the problem. I really wish we could get rid of the
tabs once and for all soon, though.

In the comment starting with "presumably" I have an assertion just below it to sanity check
that the presumption holds. I'll make the comment point to it more directly so it's clearer
that the two belong together.

As for the FIXME, I think it's OK to leave it in since the likelihood of this happening is
low and it would be ok to leave this optimization till someone really needed it, IMHO. Perhaps
I should avoid the FIXME word, though, and just say "this can be optimized".?
                
      was (Author: dagw):
    Thanks, Bryan! As for tabs, I gave up trying to retain tabs years ago, I try to make my
patches only use blanks for all new code. I know it looks 
awkward when one reads the patch in a tab=8 context, but alas... I set my tab width to 4 in
Emacs before I inspect patches to avoid the problem. I really wish we could get rid of the
tabs once and for all soon, though.

In the comment starting with "presumably" I have an assertion just below it to sanity check
that the presumption holds. I'll make the comment point to it more directly so it's clearer
that the two belong together.

As for the FIXME, I think it's OK to leave it in since the likelihood of this happening is
low and it would be ok to leave this optimization till someone really needed it, IMHO.
                  
> Allow ORDER BY and FETCH/OFFSET in set operands
> -----------------------------------------------
>
>                 Key: DERBY-6008
>                 URL: https://issues.apache.org/jira/browse/DERBY-6008
>             Project: Derby
>          Issue Type: Improvement
>          Components: SQL
>            Reporter: Dag H. Wanvik
>            Assignee: Dag H. Wanvik
>         Attachments: derby-6008-a.diff, derby-6008-a.stat, derby-6008-b.diff, derby-6008-b.stat,
derby-6008-c.diff, derby-6008-c.stat, derby-6008-d.diff, derby-6008-d.stat
>
>
> Currently, Derby doesn't allow ORDER BY nested in a set operand, e.g. in the following
construct:
> (select i from t1 order by j offset 1 row)    union 
> (select i from t2 order by j desc offset 2 rows)
> This is allowed by the standard, as far as I can understand, cf. this quote from section
7.12 in SQL 2011:
> <query expression body> ::=
>     <query term>
> |   <query expression body> UNION [ ALL | DISTINCT ]
>   [ <corresponding spec> ] <query term>
> |   <query expression body> EXCEPT [ ALL | DISTINCT ]
>   [ <corresponding spec> ] <query term>
> <query term> ::=
>    <query primary>
> |  <query term> INTERSECT [ ALL | DISTINCT ]
>    [ <corresponding spec> ] <query primary>
> <query primary> ::=
>    <simple table>
>   |  <left paren> <query expression body>
>      [ <order by clause> ] [ <result offset clause> ] [ <fetch first clause>
] <right paren>
> I.e. the left paren chooses the second alternative in the production for <query primary>.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Mime
View raw message