[
https://issues.apache.org/jira/browse/DERBY-4720?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rick Hillegas updated DERBY-4720:
---------------------------------
Attachment: derby-4720-01-ac-allowBooleanExpressions.diff
Attaching derby-4720-01-ac-allowBooleanExpressions.diff. This patch makes it
possible to use boolean-valued expressions in several situations required by
the SQL Standard. The tests ran cleanly for me.
The grammar was changed as follows:
1) The inSelectClause arguments were rototilled out of productions which return
ValueNode. Those arguments were added when the BOOLEAN datatype was disabled.
Their purpose was to reject BOOLEAN-valued expressions in the situations listed
in (2) below. This rototill accounts for most of the changes to the parser.
2) Calls to additiveExpression() were replaced by calls to orExpression() in
the following productions. This allows unparenthesized boolean expressions to
appear in SELECT lists, as columns in VALUES constructors, as arguments to
FUNCTIONs and PROCEDUREs, and as targets of SET clauses. The Derby productions
do not map exactly to the productions in the SQL grammar. The orExpression()
production lies above additiveExpression() in Derby's grammar. That is, it is
more general. It is possible that an even more general production might bring
us even closer to the SQL Standard. However, orExpression() seemed to me to be
the minimal production required to allow unparenthesized boolean-valued
expressions. Generalizing this further seems to me to be beyond the scope of
this JIRA.
i) derivedColumn() (SELECT list)
ii) rowValueConstructor() (VALUES clause)
iii) methodParameter() (routine arguments)
iv) updateSource() (SET clauses)
Touches the following files:
---------
M java/engine/org/apache/derby/impl/sql/compile/sqlgrammar.jj
Grammar changes described above.
---------
M
java/testing/org/apache/derbyTesting/functionTests/tests/lang/BooleanValuesTest.java
New test case. More extensive testing is provided by the revised tests below.
---------
M java/testing/org/apache/derbyTesting/functionTests/tests/lang/logop.sql
M
java/testing/org/apache/derbyTesting/functionTests/tests/lang/valuesclause.sql
M
java/testing/org/apache/derbyTesting/functionTests/tests/lang/subquery2.sql
M java/testing/org/apache/derbyTesting/functionTests/tests/lang/schemas.sql
M java/testing/org/apache/derbyTesting/functionTests/master/subquery.out
M java/testing/org/apache/derbyTesting/functionTests/master/logop.out
M
java/testing/org/apache/derbyTesting/functionTests/master/valuesclause.out
M java/testing/org/apache/derbyTesting/functionTests/master/subquery2.out
M java/testing/org/apache/derbyTesting/functionTests/master/schemas.out
M java/testing/org/apache/derbyTesting/functionTests/master/aggregate.out
Changes to existing tests to account for the fact that boolean expressions can
now appear in other situations required by the SQL Standard.
> Allow boolean-valued expressions in select lists
> ------------------------------------------------
>
> Key: DERBY-4720
> URL: https://issues.apache.org/jira/browse/DERBY-4720
> Project: Derby
> Issue Type: Improvement
> Components: SQL
> Affects Versions: 10.6.1.0
> Reporter: Rick Hillegas
> Assignee: Rick Hillegas
> Attachments: derby-4720-01-ac-allowBooleanExpressions.diff
>
>
> When the BOOLEAN datatype was disabled, the grammar was peppered with special
> checks to make sure that expressions like "a > 10" did not appear in the
> SELECT list. Perhaps this was done to reduce the number of cases in which
> BOOLEAN values could be materialized as columns in queries. That is, however,
> an unsatisfying reason because you could always materialize BOOLEAN columns
> by selecting from certain system tables. In any event, the SQL grammar allows
> these expressions in the SELECT list and we should re-enable them as part of
> exposing BOOLEAN as a full-fledged Derby datatype.
> I intend to re-enable these expressions per the SQL spec. If anyone knows of
> a reason why this should not be allowed, please speak up. Thanks.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
