Difference: TapNotes20140718 (1 vs. 11)

Revision 112014-10-20 - MarkusDemleitner

 
META TOPICPARENT name="DaveMorris"
Notes from the TAP/ADQL splinter session on Wednesday 21 May 2014 at the IVOA Interop meeting at ESAC.

During the meeting the group reviewed a number of proposed changes to TAP and ADQL described in the TAP Implementation Notes Version 1.0.

The following section lists the recommendations agreed at the meeting for each of the changes that were reviewed.

After each section there is a table for adding feedback. Please add your vote to indicate

  • +1 You agree with the decision
  • 0 You don't mind either way
  • -1 You disagree with the decision
If you vote to disagree please provide a brief explanation describing why (or a link to a new page if you prefer).

If you feel that an item needs more discussion please feel free to raise it on the working group mailing list.

Thank you for your feedback. -- DaveMorris - 2014-09-04

Example item

Some text describing the item, with a reference to the original item in the TAP Implementation Notes.

May 2014 Interop

A brief summary of the discussion at the May Interop.

Community feedback
Name date vote notes
MarcoMolinaro 2014-09-04 +1 Yes, good idea
DaveMorris 2014-09-04 0 Ok, as long as it is optional
DaveMorris 2014-09-04 -1 It isn't the right colour, our users prefer blue background.

Separator Nonterminal

This item proposes two options to clarify the use of whitespace and comments in ADQL.

One option for such a clarification is to amend section 2.1 of std:ADQL with a subsection 2.1.4, "Tokens and literals", containing text like the following (taken essentially from std:SQL1992).

  • Any token may be followed by a separator. A nondelimiter token shall be followed by a delimiter token or a separator.
Since the full rules for the separator are somewhat more complex in std:ADQL, an attractive alternative could be to omit the separator nonterminal from the grammar and to just note:

  • Whitespace and comments can occur wherever they can occur in std:SQL1992.

May 2014 Interop

Accepted as errata - It was agreed that this item should be included in the errata note for the current, std:ADQL-20081030, version of the standard.

Community feedback
Name date vote notes
DaveMorris 2014-09-04 +1 Happy with either option
MarcoMolinaro 2014-09-17 +1 Prefer the II solution
       

Type System

This item proposes adding new section to introduce a notion of types into section 2 of the std:ADQL standard.

See original text for details of the proposed type mappings.

[TODO insert table here]

May 2014 Interop

Accepted for next version - It was agreed that this item should be discussed further, with a view to including it in the next (minor) version of the std:ADQL standard.

Community feedback
Name date vote notes
DaveMorris 2014-09-04 +1 Yes, but needs some clarification (see below).
MarcoMolinaro 2014-09-17 +1  
       

Transporting TIMESTAMP, POINT and REGION as strings should not imply the ADQL string concatenation operators are applicable. -- DaveMorris - 2014-09-04

Empty Coordinate Systems

This item proposes deprecating the string-valued first argument for the geometry constructors ( BOX, CIRCLE, POINT, POLYGON).

May 2014 Interop

Requires further discussion - It was agreed that the proposal needs more work done on it before it could be included in the std:ADQL standard.

Community feedback
Name date vote notes
DaveMorris 2014-09-04 +1  
MarcoMolinaro 2014-09-17 +1  
       

Explanation of optional features

This item proposes adding a section of text to both the std:TAP and std:ADQL specifications that clarifies how optional features are described.

May 2014 Interop

Accepted for next version - It was agreed that this item should be discussed further, with a view to including it in the next (minor) version of the std:ADQL standard.

Community feedback
Name date vote notes
DaveMorris 2014-09-04 +1 I think this is needed
MarcoMolinaro 2014-09-17 +1  
       

Simple Crossmatch Function

This item proposes adding a simple positional crossmatch function to std:ADQL.

May 2014 Interop

Requires further discussion - It was agreed that the proposal needs more work done on it before it could be included in the std:ADQL standard.

  • It was agreed that this would be a useful feature for end users
  • It was noted that adding this feature could be difficult to implement
  • It was noted that part of the rationale for the IVOA services was to implement difficult things on the server side, making things easier for the end user

Community feedback
Name date vote notes
DaveMorris 2014-09-04 +1 Like the idea, needs more work
MarcoMolinaro 2014-09-17 +1  
       

No type-based decay of INTERSECTS

This item proposes deprecating the use of POINT as the first parameter to INTERSECTS.

May 2014 Interop

Accepted for next version - It was agreed that the proposed text should be included in the next (minor) version of the std:ADQL standard.

Community feedback
Name date vote notes
DaveMorris 2014-09-04 +1  
MarcoMolinaro 2014-09-17 +1  
       

Generalized user defined functions

This item proposes allowing user defined functions to return geometric types.

May 2014 Interop

It was agreed that there should be no restriction on the return types of User Defined Functions.

Accepted as errata - It was agreed that this should be included in the errata note for the current, std:ADQL-20081030, version of the standard.

Futher discussion - It was also noted that the SimDAL working group would like to be able to define table value functions in std:ADQL. It was agreed to continue the discussion to find a way of adding support for table value functions in a future version of the std:ADQL standard.

Community feedback
Name date vote notes
DaveMorris 2014-09-04 +1  
MarcoMolinaro 2014-09-17 +1  
       

Case-Insensitive String Comparisons

This item proposes adding functions and operators for to support case-insensitive string comparisons.

May 2014 Interop

Accepted for next version - This item was discussed by members of the working group at the May 2014 IVOA Interop meeting.

It was agreed that the following functions should be included as an optional feature in the next (minor) version of the std:ADQL standard.

  • UPPER
  • LOWER
It was agreed that the following operator should be included as an optional feature in the next (minor) version of the std:ADQL standard.

  • ILIKE

Community feedback
Name date vote notes
DaveMorris 2014-09-04 +1  
MarcoMolinaro 2014-09-17 +1  
Changed:
<
<
MarkusDemleitner 2014-10-05 -1 While support the proposed features per se, I don't think they should be optional. They're not hard to implement on all DB engines I'm aware of, and optional features are always a pain in so many ways. You'd at least have to say how clients are expected to discover support for them if you go for optional.
>
>
MarkusDemleitner 2014-10-05 -1 While support the proposed features per se, I don't think they should be optional. They're not hard to implement on all DB engines I'm aware of, and optional features are always a pain in so many ways. You'd at least have to say how clients are expected to discover support for them if you go for optional.
 
       
Added:
>
>		By popular demand, here's a support matrix for these:

Vendor UPPER LOWER ILIKE verified by
MySQL YES YES LIKE is case-insensitive by default; there's COLLATE to make it case-sensitive Marco - 2014-10-15
SQLServer YES YES Default case sensitivity is a database property; it can be set by column but not by operator. Theresa- 2014-10-11
Postgres YES YES YES Markus 2014-10-20
Postgres YES YES LIKE is case insensitive by default, case folding configurable by column Markus 2014-10-20
| |
 
Added:
>
>		Hm, I guess that's pretty much nailed it for ILIKE. For the others, it was suggested we agree on either upper or lower in order to increase the chances that case-normalisation will hit indices. So -- shall it be UPPER or LOWER or both?

 

Set operators

This item proposes adding support for the UNION, EXCEPT and INTERSECT operators.

May 2014 Interop

Accepted for next version - This item was discussed by members of the working group at the May 2014 IVOA Interop meeting.

It was agreed that the following operators should be included as required operators in the next (minor) version of the std:ADQL standard.

  • UNION
  • EXCEPT
  • INTERSECT
It was agreed that the text describing the set operators in the std:ADQL standard should include the following caveats.

  • The set operands MUST produce the same number of columns
  • The corresponding columns in the operands MUST have the same data types
  • The corresponding columns in the operands SHOULD have the same metadata
  • The metadata for the results SHOULD be generated from the left-hand operand

Community feedback
Name date vote notes
DaveMorris 2014-09-04 -1 I agree with the proposal (+1), but we need to confirm which platforms support what operators (see below)
MarcoMolinaro 2014-09-17 +1  
MarkusDemleitner 2014-10-05 +1  
       

The Oracle database platform includes support for UNION and INTERSECT, but not EXCEPT. However, Oracle's MINUS operator appears to be equivalent to EXCEPT.

If we make these operators as a required feature of std:ADQL then it means service implementations based on Oracle will have to parse and translate ADQL queries.

This may not be an issue, but it will be the first time we have (knowingly) added a feature to std:ADQL that requires service implementations to parse and translate ADQL queries.

-- DaveMorris - 2014-09-04

Please contribute your knowledge to the table below to help us build a map of which platforms support which operators.

Vendor version UNION INTERSECT EXCEPT verified by
SQLServer   YES YES YES DaveMorris - 2014-09-04
Sybase          
Oracle   YES YES (see below)  
PostgreSQL   YES YES YES  
MySQL   YES NO NO MarcoMolinaro - 2014-09-17
Derby          
HSQLBD          
SQLLite          

Oracle - The Oracle database platform supports the UNION and INTERSECT, operators directly, and the MINUS operator is equivalent to EXCEPT.

MySQL - The MySQL DBMS doesn't support EXCEPT and INTERSECT. Query translations are needed in both cases.

Adding a Boolean Type

This item proposes adding a BOOLEAN type to std:ADQL.

May 2014 Interop

Requires further discussion - This item was discussed by members of the working group at the May 2014 IVOA Interop meeting.

It was agreed that although making these changes would be a good thing, more work needs to be done on identifying and solving potential compatibility issues before the changes can be included in the std:ADQL standard.

  • It was agreed that BOOLEAN data type would be a useful feature to add
  • It was agreed that changing the return type of CONTAINS() to be a BOOLEAN would make it easier to use
  • It was agreed that making these changes could cause compatibility issues which could not be addressed in a (minor) increment of the std:ADQL standard
  • It was agreed that both of these changes should be considered for a future (major) increment of the std:ADQL standard
Based on the points raised at the May 2014 Interop we would like to split this into two separate proposals and ask for your feedback on each proposal.

Adding a Boolean Type

The first proposal is to add support for a BOOLEAN type to std:ADQL, without changing the return type of CONTAINS().

This would avoid the potential compatibility issues raised at the May 2014 Interop.

The general concensus at the May 2014 Interop was that a BOOLEAN data type would be useful, and that adding it as a new type would not cause compatibility issues.

Community feedback
Name date vote notes
DaveMorris 2014-09-04 +1 Yes to adding BOOLEAN
MarcoMolinaro 2014-09-17 +1  
Changed:
<
<
MarkusDemleitner 2014-10-05 +1 Yes to allowing ADQL engines to return boolean columns. I'm fairly skeptical on allowing boolean-typed column references ("WHERE my_col") on grounds that parse errors will probably be harder to understand for users with them.
>
>
MarkusDemleitner 2014-10-05 +1 Yes to allowing ADQL engines to return boolean columns. I'm fairly skeptical on allowing boolean-typed column references ("WHERE my_col") on grounds that parse errors will probably be harder to understand for users with them.
 
       

changing the return type of CONTAINS()

The second proposal is to change the return type of CONTAINS().

This is the part that would potentially cause compatibility issues with existing services and clients.

Community feedback
Name date vote notes
DaveMorris 2014-09-04 +1 Yes to changing CONTAINS()
MarcoMolinaro 2014-09-17 +1  
MarkusDemleitner 2014-10-05 -1 If we want this, it's definitely a matter for a major version, and I'd first like to see the impact of boolean-valued expressions outside of comparisons
       

Casting to Unit

This item proposes adding a new function IN_UNIT(expr, ) which would convert values in one unit into another.

May 2014 Interop

Requires further discussion - It was agreed that the proposal needs more work done on it before it could included in the std:ADQL standard.

  • It was agreed that scaling conversions would not be difficult to implement
  • It was agreed that conversion between wavelength and frequency would be difficult to implement consistently
  • It was agreed that unit conversions would be most useful in a SELECT list
  • It was agreed that unit conversions would be most difficult to implement in a WHERE clause

Community feedback
Name date vote notes
DaveMorris 2014-09-04 0  
MarcoMolinaro 2014-09-17 0  
MarkusDemleitner 2014-10-05 +1 Implementations should be given some leeway in what they'd accept; I'd consider it fine if they were only required to allow unit casts on single columns, and restrict what pairs of unit strings they support.
       

Column References with UCD Patterns

This item proposes adding a pre-processing macro that locates columns based on their UCD.

May 2014 Interop

Requires further discussion - It was agreed that the proposal needs more work done on it before it could be considered ready to be included in the std:ADQL standard.

Community feedback
Name date vote notes
DaveMorris 2014-09-04 +1 Good idea but needs more work
MarcoMolinaro 2014-09-17 0  
MarkusDemleitner 2014-10-05 +1 I believe the main issue here is what do to when no or multiple columns match
       

Modulo operator

This item proposes adding the modulus operator x % y to the std:ADQL grammar.

May 2014 Interop

Rejected - It was agreed that the benefits of adding the x % y operator syntax were outweighed by cost of compatibility issues caused by adding a new required operator to the std:ADQL grammar.

Community feedback
Name date vote notes
DaveMorris 2014-09-04 +1 Disclosure - this is one of mine and I'm sneaking it back in (see below)
MarcoMolinaro 2014-09-17 +1  
Changed:
<
<
MarkusDemleitner 2014-10-05 0 I'm unconvinced new syntax that doesn't add capabilities is worth the effort.
>
>
MarkusDemleitner 2014-10-05 0 I'm unconvinced new syntax that doesn't add capabilities is worth the effort.
 
       

If this is the only required operator we are adding, then it is probably not worth the potential compatibility issues.

However, if we are updating the std:ADQL grammar to add UNION, EXCEPT and INTERSECT as operators, does adding the x % y operator cause any additional compatibility issues ? -- DaveMorris - 2014-09-04

Bitwise operators

This item proposes adding support for the AND, OR, XOR and NOT bitwise operations and hexadecimal literals to the [std:ADQL] grammar.

May 2014 Interop

Accepted for next version - It was agreed that hexadecimal literal values should be included in the next (minor) version of the std:ADQL standard.

Accepted for next version - It was agreed that the following functions should be included as an optional feature in the next (minor) version of the std:ADQL standard.

  • BIT_AND(x, y)
  • BIT_OR(x, y)
  • BIT_XOR(x, y)
  • BIT_NOT(x)
Rejected - It was agreed that the benefits of adding the operator, [exp] op [exp], syntax for each operation were outweighed by cost of compatibility issues caused by adding new operators to the std:ADQL grammar.

However, if we are updating the std:ADQL grammar to add UNION, EXCEPT and INTERSECT as operators, does adding the [exp] op [exp] for each of the bitwise operations cause any additional compatibility issues ? -- DaveMorris - 2014-09-04

Community feedback
Name date vote notes
DaveMorris 2014-09-04 +2 Please vote +1 to accept the functions, +2 to accept the operators
MarcoMolinaro 2014-09-17 +1  
MarkusDemleitner 2014-10-05 +1 The functions seem useful and implementable to me; I don't see a big benefit in making the functionality available through operators.
       

CAST operator

This item proposes adding a limited form of the CAST operator to the std:ADQL grammar.

This proposal specifically limited the CAST operation to numeric data types only, and excluded CAST to and from character strings.

May 2014 Interop

Accepted for next version - It was agreed that the CAST operator should be including as a required operator in the next (minor) version of the std:ADQL standard.

It was agreed that the set of type conversions should be discussed further, with a view to finalizing the set of conversions supported in the next (minor) version of the [std:ADQL] standard.

Community feedback
Name date vote notes
DaveMorris 2014-09-04 +1  
MarcoMolinaro 2014-09-17 +1  
MarkusDemleitner 2014-10-05 +1  
       

Revision 102014-10-05 - MarkusDemleitner

 
META TOPICPARENT name="DaveMorris"
Notes from the TAP/ADQL splinter session on Wednesday 21 May 2014 at the IVOA Interop meeting at ESAC.

During the meeting the group reviewed a number of proposed changes to TAP and ADQL described in the TAP Implementation Notes Version 1.0.

The following section lists the recommendations agreed at the meeting for each of the changes that were reviewed.

After each section there is a table for adding feedback. Please add your vote to indicate

  • +1 You agree with the decision
  • 0 You don't mind either way
  • -1 You disagree with the decision
Deleted:
<
<
 If you vote to disagree please provide a brief explanation describing why (or a link to a new page if you prefer).

If you feel that an item needs more discussion please feel free to raise it on the working group mailing list.

Thank you for your feedback. -- DaveMorris - 2014-09-04

Example item

Added:
>
>
 Some text describing the item, with a reference to the original item in the TAP Implementation Notes.

May 2014 Interop
Added:
>
>
 A brief summary of the discussion at the May Interop.

Community feedback
Name date vote notes
MarcoMolinaro 2014-09-04 +1 Yes, good idea
DaveMorris 2014-09-04 0 Ok, as long as it is optional
DaveMorris 2014-09-04 -1 It isn't the right colour, our users prefer blue background.

Added:
>
>
 

Separator Nonterminal

Added:
>
>
 This item proposes two options to clarify the use of whitespace and comments in ADQL.

One option for such a clarification is to amend section 2.1 of std:ADQL with a subsection 2.1.4, "Tokens and literals", containing text like the following (taken essentially from std:SQL1992).

  • Any token may be followed by a separator. A nondelimiter token shall be followed by a delimiter token or a separator.
Deleted:
<
<
 Since the full rules for the separator are somewhat more complex in std:ADQL, an attractive alternative could be to omit the separator nonterminal from the grammar and to just note:

  • Whitespace and comments can occur wherever they can occur in std:SQL1992.

May 2014 Interop
Deleted:
<
<		Accepted as errata - It was agreed that this item should be included in the errata note for the current, std:ADQL-20081030, version of the standard.
 
Added:
>
>		Accepted as errata - It was agreed that this item should be included in the errata note for the current, std:ADQL-20081030, version of the standard.
 
Community feedback
Changed:
<
<
Name date vote notes
>
>
Name date vote notes
 
DaveMorris 2014-09-04 +1 Happy with either option
MarcoMolinaro 2014-09-17 +1 Prefer the II solution
Changed:
<
<
       
>
>
       
 
Added:
>
>
 

Type System

Added:
>
>
 This item proposes adding new section to introduce a notion of types into section 2 of the std:ADQL standard.
Changed:
<
<		See original text for details of the proposed type mappings.
>
>		See original text for details of the proposed type mappings.
  [TODO insert table here]

May 2014 Interop
Deleted:
<
<		Accepted for next version - It was agreed that this item should be discussed further, with a view to including it in the next (minor) version of the std:ADQL standard.
 
Added:
>
>		Accepted for next version - It was agreed that this item should be discussed further, with a view to including it in the next (minor) version of the std:ADQL standard.
 
Community feedback
Changed:
<
<
Name date vote notes
>
>
Name date vote notes
 
DaveMorris 2014-09-04 +1 Yes, but needs some clarification (see below).
MarcoMolinaro 2014-09-17 +1  
Changed:
<
<
       
>
>
       
 
Changed:
<
<		Transporting TIMESTAMP, POINT and REGION as strings should not imply the ADQL string concatenation operators are applicable.
>
>		Transporting TIMESTAMP, POINT and REGION as strings should not imply the ADQL string concatenation operators are applicable. -- DaveMorris - 2014-09-04
Deleted:
<
<		-- DaveMorris - 2014-09-04
 

Added:
>
>
 

Empty Coordinate Systems

Deleted:
<
<		This item proposes deprecating the string-valued first argument for the geometry constructors (BOX, CIRCLE, POINT, POLYGON).
 
Added:
>
>		This item proposes deprecating the string-valued first argument for the geometry constructors ( BOX, CIRCLE, POINT, POLYGON).
 
May 2014 Interop
Deleted:
<
<		Requires further discussion - It was agreed that the proposal needs more work done on it before it could be included in the std:ADQL standard.
 
Added:
>
>		Requires further discussion - It was agreed that the proposal needs more work done on it before it could be included in the std:ADQL standard.
 
Community feedback
Changed:
<
<
Name date vote notes
>
>
Name date vote notes
 
DaveMorris 2014-09-04 +1  
MarcoMolinaro 2014-09-17 +1  
Changed:
<
<
       
>
>
       
 
Added:
>
>
 

Explanation of optional features

Deleted:
<
<		This item proposes adding a section of text to both the std:TAP and std:ADQL specifications that clarifies how optional features are described.
 
Added:
>
>		This item proposes adding a section of text to both the std:TAP and std:ADQL specifications that clarifies how optional features are described.
 
May 2014 Interop
Deleted:
<
<		Accepted for next version - It was agreed that this item should be discussed further, with a view to including it in the next (minor) version of the std:ADQL standard.
 
Added:
>
>		Accepted for next version - It was agreed that this item should be discussed further, with a view to including it in the next (minor) version of the std:ADQL standard.
 
Community feedback
Changed:
<
<
Name date vote notes
>
>
Name date vote notes
 
DaveMorris 2014-09-04 +1 I think this is needed
MarcoMolinaro 2014-09-17 +1  
Changed:
<
<
       
>
>
       
 
Added:
>
>
 

Simple Crossmatch Function

Deleted:
<
<		This item proposes adding a simple positional crossmatch function to std:ADQL.
 
Added:
>
>		This item proposes adding a simple positional crossmatch function to std:ADQL.
 
May 2014 Interop
Deleted:
<
<		Requires further discussion - It was agreed that the proposal needs more work done on it before it could be included in the std:ADQL standard.
 
Added:
>
>		Requires further discussion - It was agreed that the proposal needs more work done on it before it could be included in the std:ADQL standard.
 
  • It was agreed that this would be a useful feature for end users
  • It was noted that adding this feature could be difficult to implement
  • It was noted that part of the rationale for the IVOA services was to implement difficult things on the server side, making things easier for the end user

Community feedback
Changed:
<
<
Name date vote notes
>
>
Name date vote notes
 
DaveMorris 2014-09-04 +1 Like the idea, needs more work
MarcoMolinaro 2014-09-17 +1  
Changed:
<
<
       
>
>
       
 
Added:
>
>
 

No type-based decay of INTERSECTS

Deleted:
<
<		This item proposes deprecating the use of POINT as the first parameter to INTERSECTS.
 
Added:
>
>		This item proposes deprecating the use of POINT as the first parameter to INTERSECTS.
 
May 2014 Interop
Deleted:
<
<		Accepted for next version - It was agreed that the proposed text should be included in the next (minor) version of the std:ADQL standard.
 
Added:
>
>		Accepted for next version - It was agreed that the proposed text should be included in the next (minor) version of the std:ADQL standard.
 
Community feedback
Changed:
<
<
Name date vote notes
>
>
Name date vote notes
 
DaveMorris 2014-09-04 +1  
MarcoMolinaro 2014-09-17 +1  
Changed:
<
<
       
>
>
       
 
Added:
>
>
 

Generalized user defined functions

Deleted:
<
<		This item proposes allowing user defined functions to return geometric types.
 
Added:
>
>		This item proposes allowing user defined functions to return geometric types.
 
May 2014 Interop
Added:
>
>
 It was agreed that there should be no restriction on the return types of User Defined Functions.
Changed:
<
<		Accepted as errata -
>
>		Accepted as errata - It was agreed that this should be included in the errata note for the current, std:ADQL-20081030, version of the standard.
Deleted:
<
<		It was agreed that this should be included in the errata note for the current, std:ADQL-20081030, version of the standard.
 
Changed:
<
<		Futher discussion -
>
>		Futher discussion - It was also noted that the SimDAL working group would like to be able to define table value functions in std:ADQL. It was agreed to continue the discussion to find a way of adding support for table value functions in a future version of the std:ADQL standard.
Deleted:
<
<		It was also noted that the SimDAL working group would like to be able to define table value functions in std:ADQL. It was agreed to continue the discussion to find a way of adding support for table value functions in a future version of the std:ADQL standard.
 
Community feedback
Changed:
<
<
Name date vote notes
>
>
Name date vote notes
 
DaveMorris 2014-09-04 +1  
MarcoMolinaro 2014-09-17 +1  
Changed:
<
<
       
>
>
       
 
Added:
>
>
 

Case-Insensitive String Comparisons

Deleted:
<
<		This item proposes adding functions and operators for to support case-insensitive string comparisons.
 
Added:
>
>		This item proposes adding functions and operators for to support case-insensitive string comparisons.
 
May 2014 Interop
Deleted:
<
<		Accepted for next version - This item was discussed by members of the working group at the May 2014 IVOA Interop meeting.
 
Changed:
<
<		It was agreed that the following functions should be included as an optional feature in the
>
>		Accepted for next version - This item was discussed by members of the working group at the May 2014 IVOA Interop meeting.
Deleted:
<
<		next (minor) version of the std:ADQL standard.
 
Added:
>
>		It was agreed that the following functions should be included as an optional feature in the next (minor) version of the std:ADQL standard.
 
  • UPPER
  • LOWER
Added:
>
>		It was agreed that the following operator should be included as an optional feature in the next (minor) version of the std:ADQL standard.
 
Deleted:
<
<		It was agreed that the following operator should be included as an optional feature in the next (minor) version of the std:ADQL standard.
 
  • ILIKE

Community feedback
Changed:
<
<
Name date vote notes
>
>
Name date vote notes
 
DaveMorris 2014-09-04 +1  
MarcoMolinaro 2014-09-17 +1  
Changed:
<
<
       
>
>
MarkusDemleitner 2014-10-05 -1 While support the proposed features per se, I don't think they should be optional. They're not hard to implement on all DB engines I'm aware of, and optional features are always a pain in so many ways. You'd at least have to say how clients are expected to discover support for them if you go for optional.
Added:
>
>
       
 
Added:
>
>
 

Set operators

Deleted:
<
<		This item proposes adding support for the UNION, EXCEPT and INTERSECT operators.
 
Added:
>
>		This item proposes adding support for the UNION, EXCEPT and INTERSECT operators.
 
May 2014 Interop
Deleted:
<
<		Accepted for next version - This item was discussed by members of the working group at the May 2014 IVOA Interop meeting.
 
Changed:
<
<		It was agreed that the following operators should be included as required operators in the next
>
>		Accepted for next version - This item was discussed by members of the working group at the May 2014 IVOA Interop meeting.
Deleted:
<
<		(minor) version of the std:ADQL standard.
 
Added:
>
>		It was agreed that the following operators should be included as required operators in the next (minor) version of the std:ADQL standard.
 
  • UNION
  • EXCEPT
  • INTERSECT
Added:
>
>		It was agreed that the text describing the set operators in the std:ADQL standard should include the following caveats.
 
Deleted:
<
<		It was agreed that the text describing the set operators in the std:ADQL standard should include the following caveats.
 
  • The set operands MUST produce the same number of columns
  • The corresponding columns in the operands MUST have the same data types
  • The corresponding columns in the operands SHOULD have the same metadata
  • The metadata for the results SHOULD be generated from the left-hand operand

Community feedback
Changed:
<
<
Name date vote notes
>
>
Name date vote notes
 
DaveMorris 2014-09-04 -1 I agree with the proposal (+1), but we need to confirm which platforms support what operators (see below)
MarcoMolinaro 2014-09-17 +1  
Changed:
<
<
       
>
>
MarkusDemleitner 2014-10-05 +1  
Added:
>
>
       
 
Changed:
<
<		The Oracle database platform includes support for UNION and INTERSECT, but not EXCEPT.
>
>		The Oracle database platform includes support for UNION and INTERSECT, but not EXCEPT. However, Oracle's MINUS operator appears to be equivalent to EXCEPT.
Deleted:
<
<		However, Oracle's MINUS operator appears to be equivalent to EXCEPT.
 
Changed:
<
<		If we make these operators as a required feature of std:ADQL
>
>		If we make these operators as a required feature of std:ADQL then it means service implementations based on Oracle will have to parse and translate ADQL queries.
Deleted:
<
<		then it means service implementations based on Oracle will have to parse and translate ADQL queries.
 
Changed:
<
<		This may not be an issue, but it will be the first time we have (knowingly) added
>
>		This may not be an issue, but it will be the first time we have (knowingly) added a feature to std:ADQL that requires service implementations to parse and translate ADQL queries.
Deleted:
<
<		a feature to std:ADQL that requires service implementations to parse and translate ADQL queries.
  -- DaveMorris - 2014-09-04
Changed:
<
<		Please contribute your knowledge to the table below to help us build a map of which
>
>		Please contribute your knowledge to the table below to help us build a map of which platforms support which operators.
Deleted:
<
<		platforms support which operators.
 
Changed:
<
<
Vendor version UNION INTERSECT EXCEPT verified by
SQLServer   YES YES YES DaveMorris - 2014-09-04
Sybase          
Oracle   YES YES (see below)  
PostgreSQL   YES YES YES  
MySQL   YES NO NO MarcoMolinaro - 2014-09-17
Derby          
HSQLBD          
SQLLite          
>
>
Vendor version UNION INTERSECT EXCEPT verified by
SQLServer   YES YES YES DaveMorris - 2014-09-04
Sybase          
Oracle   YES YES (see below)  
PostgreSQL   YES YES YES  
MySQL   YES NO NO MarcoMolinaro - 2014-09-17
Derby          
HSQLBD          
SQLLite          
 
Changed:
<
<		Oracle - The Oracle database platform supports the UNION and INTERSECT,
>
>		Oracle - The Oracle database platform supports the UNION and INTERSECT, operators directly, and the MINUS operator is equivalent to EXCEPT.
Deleted:
<
<		operators directly, and the MINUS operator is equivalent to EXCEPT.
  MySQL - The MySQL DBMS doesn't support EXCEPT and INTERSECT. Query translations are needed in both cases.

Added:
>
>
 

Adding a Boolean Type

Deleted:
<
<		This item proposes adding a BOOLEAN type to std:ADQL.
 
Added:
>
>		This item proposes adding a BOOLEAN type to std:ADQL.
 
May 2014 Interop
Deleted:
<
<		Requires further discussion - This item was discussed by members of the working group at the May 2014 IVOA Interop meeting.
 
Changed:
<
<		It was agreed that although making these changes would be a good thing, more work needs to be
>
>		Requires further discussion - This item was discussed by members of the working group at the May 2014 IVOA Interop meeting.
Deleted:
<
<		done on identifying and solving potential compatibility issues before the changes can be included in the std:ADQL standard.
 
Added:
>
>		It was agreed that although making these changes would be a good thing, more work needs to be done on identifying and solving potential compatibility issues before the changes can be included in the std:ADQL standard.
 
  • It was agreed that BOOLEAN data type would be a useful feature to add
  • It was agreed that changing the return type of CONTAINS() to be a BOOLEAN would make it easier to use
  • It was agreed that making these changes could cause compatibility issues which could not be addressed in a (minor) increment of the std:ADQL standard
  • It was agreed that both of these changes should be considered for a future (major) increment of the std:ADQL standard
Added:
>
>		Based on the points raised at the May 2014 Interop we would like to split this into two separate proposals and ask for your feedback on each proposal.
 
Deleted:
<
<		Based on the points raised at the May 2014 Interop we would like to split this into two separate proposals and ask for your feedback on each proposal.
 

Adding a Boolean Type

Deleted:
<
<		The first proposal is to add support for a BOOLEAN type to std:ADQL, without changing the return type of CONTAINS().
 
Added:
>
>		The first proposal is to add support for a BOOLEAN type to std:ADQL, without changing the return type of CONTAINS().
 This would avoid the potential compatibility issues raised at the May 2014 Interop.
Changed:
<
<		The general concensus at the May 2014 Interop was that a BOOLEAN data type would be useful, and that adding it as a new type would not cause compatibility issues.
>
>		The general concensus at the May 2014 Interop was that a BOOLEAN data type would be useful, and that adding it as a new type would not cause compatibility issues.
Deleted:
<
<
 
Community feedback
Changed:
<
<
Name date vote notes
>
>
Name date vote notes
 
DaveMorris 2014-09-04 +1 Yes to adding BOOLEAN
MarcoMolinaro 2014-09-17 +1  
Changed:
<
<
       
>
>
MarkusDemleitner 2014-10-05 +1 Yes to allowing ADQL engines to return boolean columns. I'm fairly skeptical on allowing boolean-typed column references ("WHERE my_col") on grounds that parse errors will probably be harder to understand for users with them.
Added:
>
>
       
 

changing the return type of CONTAINS()

Added:
>
>
 The second proposal is to change the return type of CONTAINS().
Changed:
<
<		This is the part that would potentially cause compatibility issues
>
>		This is the part that would potentially cause compatibility issues with existing services and clients.
Deleted:
<
<		with existing services and clients.
 
Community feedback
Changed:
<
<
Name date vote notes
>
>
Name date vote notes
 
DaveMorris 2014-09-04 +1 Yes to changing CONTAINS()
MarcoMolinaro 2014-09-17 +1  
Changed:
<
<
       
>
>
MarkusDemleitner 2014-10-05 -1 If we want this, it's definitely a matter for a major version, and I'd first like to see the impact of boolean-valued expressions outside of comparisons
Added:
>
>
       
 
Added:
>
>
 

Casting to Unit

Deleted:
<
<		This item proposes adding a new function IN_UNIT(expr, ) which would convert values in one unit into another.
 
Added:
>
>		This item proposes adding a new function IN_UNIT(expr, ) which would convert values in one unit into another.
 
May 2014 Interop
Deleted:
<
<		Requires further discussion - It was agreed that the proposal needs more work done on it before it could included in the std:ADQL standard.
 
Added:
>
>		Requires further discussion - It was agreed that the proposal needs more work done on it before it could included in the std:ADQL standard.
 
  • It was agreed that scaling conversions would not be difficult to implement
  • It was agreed that conversion between wavelength and frequency would be difficult to implement consistently
  • It was agreed that unit conversions would be most useful in a SELECT list
  • It was agreed that unit conversions would be most difficult to implement in a WHERE clause

Community feedback
Changed:
<
<
Name date vote notes
>
>
Name date vote notes
 
DaveMorris 2014-09-04 0  
MarcoMolinaro 2014-09-17 0  
Changed:
<
<
       
>
>
MarkusDemleitner 2014-10-05 +1 Implementations should be given some leeway in what they'd accept; I'd consider it fine if they were only required to allow unit casts on single columns, and restrict what pairs of unit strings they support.
Added:
>
>
       
 
Added:
>
>
 

Column References with UCD Patterns

Deleted:
<
<		This item proposes adding a pre-processing macro that locates columns based on their UCD.
 
Added:
>
>		This item proposes adding a pre-processing macro that locates columns based on their UCD.
 
May 2014 Interop
Deleted:
<
<		Requires further discussion - It was agreed that the proposal needs more work done on it before it could be considered ready to be included in the std:ADQL standard.
 
Added:
>
>		Requires further discussion - It was agreed that the proposal needs more work done on it before it could be considered ready to be included in the std:ADQL standard.
 
Community feedback
Changed:
<
<
Name date vote notes
>
>
Name date vote notes
 
DaveMorris 2014-09-04 +1 Good idea but needs more work
MarcoMolinaro 2014-09-17 0  
Changed:
<
<
       
>
>
MarkusDemleitner 2014-10-05 +1 I believe the main issue here is what do to when no or multiple columns match
Added:
>
>
       
 
Added:
>
>
 

Modulo operator

Deleted:
<
<		This item proposes adding the modulus operator x % y to the std:ADQL grammar.
 
Added:
>
>		This item proposes adding the modulus operator x % y to the std:ADQL grammar.
 
May 2014 Interop
Deleted:
<
<		Rejected - It was agreed that the benefits of adding the x % y operator syntax were outweighed by cost of compatibility issues caused by adding a new required operator to the std:ADQL grammar.
 
Added:
>
>		Rejected - It was agreed that the benefits of adding the x % y operator syntax were outweighed by cost of compatibility issues caused by adding a new required operator to the std:ADQL grammar.
 
Community feedback
Changed:
<
<
Name date vote notes
>
>
Name date vote notes
 
DaveMorris 2014-09-04 +1 Disclosure - this is one of mine and I'm sneaking it back in (see below)
MarcoMolinaro 2014-09-17 +1  
Changed:
<
<
       
>
>
MarkusDemleitner 2014-10-05 0 I'm unconvinced new syntax that doesn't add capabilities is worth the effort.
Added:
>
>
       
 
Changed:
<
<		If this is the only required operator we are adding, then it is probably not
>
>		If this is the only required operator we are adding, then it is probably not worth the potential compatibility issues.
Deleted:
<
<		worth the potential compatibility issues.
 
Changed:
<
<		However, if we are updating the std:ADQL grammar to add UNION, EXCEPT and INTERSECT as operators,
>
>		However, if we are updating the std:ADQL grammar to add UNION, EXCEPT and INTERSECT as operators, does adding the x % y operator cause any additional compatibility issues ? -- DaveMorris - 2014-09-04
Deleted:
<
<		does adding the x % y operator cause any additional compatibility issues ? -- DaveMorris - 2014-09-04
 
Added:
>
>
 

Bitwise operators

Deleted:
<
<		This item proposes adding support for the AND, OR, XOR and NOT bitwise operations and hexadecimal literals to the [std:ADQL] grammar.
 
Added:
>
>		This item proposes adding support for the AND, OR, XOR and NOT bitwise operations and hexadecimal literals to the [std:ADQL] grammar.
 
May 2014 Interop
Deleted:
<
<		Accepted for next version - It was agreed that hexadecimal literal values should be included in the next (minor) version of the std:ADQL standard.
 
Changed:
<
<		Accepted for next version -
>
>		Accepted for next version - It was agreed that hexadecimal literal values should be included in the next (minor) version of the std:ADQL standard.
Deleted:
<
<		It was agreed that the following functions should be included as an optional feature in the next (minor) version of the std:ADQL standard.
 
Added:
>
>		Accepted for next version - It was agreed that the following functions should be included as an optional feature in the next (minor) version of the std:ADQL standard.
 
  • BIT_AND(x, y)
  • BIT_OR(x, y)
  • BIT_XOR(x, y)
  • BIT_NOT(x)
Added:
>
>		Rejected - It was agreed that the benefits of adding the operator, [exp] op [exp], syntax for each operation were outweighed by cost of compatibility issues caused by adding new operators to the std:ADQL grammar.
 
Changed:
<
<		Rejected -
>
>		However, if we are updating the std:ADQL grammar to add UNION, EXCEPT and INTERSECT as operators, does adding the [exp] op [exp] for each of the bitwise operations cause any additional compatibility issues ? -- DaveMorris - 2014-09-04
Deleted:
<
<		It was agreed that the benefits of adding the operator, [exp] op [exp], syntax for each operation were outweighed by cost of compatibility issues caused by adding new operators to the std:ADQL grammar.
 
Deleted:
<
<		However, if we are updating the std:ADQL grammar to add UNION, EXCEPT and INTERSECT as operators, does adding the [exp] op [exp] for each of the bitwise operations cause any additional compatibility issues ? -- DaveMorris - 2014-09-04
 
Community feedback
Changed:
<
<
Name date vote notes
>
>
Name date vote notes
 
DaveMorris 2014-09-04 +2 Please vote +1 to accept the functions, +2 to accept the operators
MarcoMolinaro 2014-09-17 +1  
Changed:
<
<
       
>
>
MarkusDemleitner 2014-10-05 +1 The functions seem useful and implementable to me; I don't see a big benefit in making the functionality available through operators.
Added:
>
>
       
 
Added:
>
>
 

CAST operator

Deleted:
<
<		This item proposes adding a limited form of the CAST operator to the std:ADQL grammar.
 
Changed:
<
<		This proposal specifically limited the CAST operation to numeric data types only,
>
>		This item proposes adding a limited form of the CAST operator to the std:ADQL grammar.
Deleted:
<
<		and excluded CAST to and from character strings.
 
Added:
>
>		This proposal specifically limited the CAST operation to numeric data types only, and excluded CAST to and from character strings.
 
May 2014 Interop
Deleted:
<
<		Accepted for next version - It was agreed that the CAST operator should be including as a required operator in the next (minor) version of the std:ADQL standard.
 
Changed:
<
<		It was agreed that the set of type conversions should be discussed further, with a view to
>
>		Accepted for next version - It was agreed that the CAST operator should be including as a required operator in the next (minor) version of the std:ADQL standard.
Deleted:
<
<		finalizing the set of conversions supported in the next (minor) version of the [std:ADQL] standard.
 
Added:
>
>		It was agreed that the set of type conversions should be discussed further, with a view to finalizing the set of conversions supported in the next (minor) version of the [std:ADQL] standard.
 
Community feedback
Changed:
<
<
Name date vote notes
>
>
Name date vote notes
 
DaveMorris 2014-09-04 +1  
MarcoMolinaro 2014-09-17 +1  
Changed:
<
<
       
>
>
MarkusDemleitner 2014-10-05 +1  
Added:
>
>
       

Revision 92014-09-25 - DaveMorris

 
META TOPICPARENT name="DaveMorris"
Notes from the TAP/ADQL splinter session on Wednesday 21 May 2014 at the IVOA Interop meeting at ESAC.

During the meeting the group reviewed a number of proposed changes to TAP and ADQL described in the TAP Implementation Notes Version 1.0.

The following section lists the recommendations agreed at the meeting for each of the changes that were reviewed.

After each section there is a table for adding feedback. Please add your vote to indicate

  • +1 You agree with the decision
  • 0 You don't mind either way
  • -1 You disagree with the decision

If you vote to disagree please provide a brief explanation describing why (or a link to a new page if you prefer).

If you feel that an item needs more discussion please feel free to raise it on the working group mailing list.

Thank you for your feedback. -- DaveMorris - 2014-09-04

Example item

Some text describing the item, with a reference to the original item in the TAP Implementation Notes.

May 2014 Interop
A brief summary of the discussion at the May Interop.

Community feedback
Name date vote notes
MarcoMolinaro 2014-09-04 +1 Yes, good idea
DaveMorris 2014-09-04 0 Ok, as long as it is optional
DaveMorris 2014-09-04 -1 It isn't the right colour, our users prefer blue background.

Separator Nonterminal

This item proposes two options to clarify the use of whitespace and comments in ADQL.

One option for such a clarification is to amend section 2.1 of std:ADQL with a subsection 2.1.4, "Tokens and literals", containing text like the following (taken essentially from std:SQL1992).

  • Any token may be followed by a separator. A nondelimiter token shall be followed by a delimiter token or a separator.

Since the full rules for the separator are somewhat more complex in std:ADQL, an attractive alternative could be to omit the separator nonterminal from the grammar and to just note:

  • Whitespace and comments can occur wherever they can occur in std:SQL1992.

May 2014 Interop
Accepted as errata - It was agreed that this item should be included in the errata note for the current, std:ADQL-20081030, version of the standard.

Community feedback
Name date vote notes
DaveMorris 2014-09-04 +1 Happy with either option
MarcoMolinaro 2014-09-17 +1 Prefer the II solution
       

Type System

This item proposes adding new section to introduce a notion of types into section 2 of the std:ADQL standard.

See original text for details of the proposed type mappings.

[TODO insert table here]

May 2014 Interop
Accepted for next version - It was agreed that this item should be discussed further, with a view to including it in the next (minor) version of the std:ADQL standard.

Community feedback
Name date vote notes
DaveMorris 2014-09-04 +1 Yes, but needs some clarification (see below).
MarcoMolinaro 2014-09-17 +1  
       

Transporting TIMESTAMP, POINT and REGION as strings should not imply the ADQL string concatenation operators are applicable. -- DaveMorris - 2014-09-04

Changed:
<
<		(Dave, you mean BLOB or CLOB? -- MarcoMolinaro - 2014-09-17) (Edited to remove BLOB -- DaveMorris - 2014-09-18)
>
>
Added:
>
>
  • Edited to remove BLOB -- DaveMorris - 2014-09-18
 

Empty Coordinate Systems

This item proposes deprecating the string-valued first argument for the geometry constructors (BOX, CIRCLE, POINT, POLYGON).

May 2014 Interop
Requires further discussion - It was agreed that the proposal needs more work done on it before it could be included in the std:ADQL standard.

Community feedback
Name date vote notes
DaveMorris 2014-09-04 +1  
MarcoMolinaro 2014-09-17 +1  
       

Explanation of optional features

This item proposes adding a section of text to both the std:TAP and std:ADQL specifications that clarifies how optional features are described.

May 2014 Interop
Accepted for next version - It was agreed that this item should be discussed further, with a view to including it in the next (minor) version of the std:ADQL standard.

Community feedback
Name date vote notes
DaveMorris 2014-09-04 +1 I think this is needed
MarcoMolinaro 2014-09-17 +1  
       

Simple Crossmatch Function

This item proposes adding a simple positional crossmatch function to std:ADQL.

May 2014 Interop
Requires further discussion - It was agreed that the proposal needs more work done on it before it could be included in the std:ADQL standard.

  • It was agreed that this would be a useful feature for end users
  • It was noted that adding this feature could be difficult to implement
  • It was noted that part of the rationale for the IVOA services was to implement difficult things on the server side, making things easier for the end user

Community feedback
Name date vote notes
DaveMorris 2014-09-04 +1 Like the idea, needs more work
MarcoMolinaro 2014-09-17 +1  
       

No type-based decay of INTERSECTS

This item proposes deprecating the use of POINT as the first parameter to INTERSECTS.

May 2014 Interop
Accepted for next version - It was agreed that the proposed text should be included in the next (minor) version of the std:ADQL standard.

Community feedback
Name date vote notes
DaveMorris 2014-09-04 +1  
MarcoMolinaro 2014-09-17 +1  
       

Generalized user defined functions

This item proposes allowing user defined functions to return geometric types.

May 2014 Interop
It was agreed that there should be no restriction on the return types of User Defined Functions.

Accepted as errata - It was agreed that this should be included in the errata note for the current, std:ADQL-20081030, version of the standard.

Futher discussion - It was also noted that the SimDAL working group would like to be able to define table value functions in std:ADQL. It was agreed to continue the discussion to find a way of adding support for table value functions in a future version of the std:ADQL standard.

Community feedback
Name date vote notes
DaveMorris 2014-09-04 +1  
MarcoMolinaro 2014-09-17 +1  
       

Case-Insensitive String Comparisons

This item proposes adding functions and operators for to support case-insensitive string comparisons.

May 2014 Interop
Accepted for next version - This item was discussed by members of the working group at the May 2014 IVOA Interop meeting.

It was agreed that the following functions should be included as an optional feature in the next (minor) version of the std:ADQL standard.

  • UPPER
  • LOWER

It was agreed that the following operator should be included as an optional feature in the next (minor) version of the std:ADQL standard.

  • ILIKE

Community feedback
Name date vote notes
DaveMorris 2014-09-04 +1  
MarcoMolinaro 2014-09-17 +1  
       

Set operators

This item proposes adding support for the UNION, EXCEPT and INTERSECT operators.

May 2014 Interop
Accepted for next version - This item was discussed by members of the working group at the May 2014 IVOA Interop meeting.

It was agreed that the following operators should be included as required operators in the next (minor) version of the std:ADQL standard.

  • UNION
  • EXCEPT
  • INTERSECT

It was agreed that the text describing the set operators in the std:ADQL standard should include the following caveats.

  • The set operands MUST produce the same number of columns
  • The corresponding columns in the operands MUST have the same data types
  • The corresponding columns in the operands SHOULD have the same metadata
  • The metadata for the results SHOULD be generated from the left-hand operand

Community feedback
Name date vote notes
DaveMorris 2014-09-04 -1 I agree with the proposal (+1), but we need to confirm which platforms support what operators (see below)
MarcoMolinaro 2014-09-17 +1  
       

The Oracle database platform includes support for UNION and INTERSECT, but not EXCEPT. However, Oracle's MINUS operator appears to be equivalent to EXCEPT.

If we make these operators as a required feature of std:ADQL then it means service implementations based on Oracle will have to parse and translate ADQL queries.

This may not be an issue, but it will be the first time we have (knowingly) added a feature to std:ADQL that requires service implementations to parse and translate ADQL queries.

-- DaveMorris - 2014-09-04

Please contribute your knowledge to the table below to help us build a map of which platforms support which operators.

Vendor version UNION INTERSECT EXCEPT verified by
SQLServer   YES YES YES DaveMorris - 2014-09-04
Sybase          
Oracle   YES YES (see below)  
PostgreSQL   YES YES YES  
MySQL   YES NO NO MarcoMolinaro - 2014-09-17
Derby          
HSQLBD          
SQLLite          

Oracle - The Oracle database platform supports the UNION and INTERSECT, operators directly, and the MINUS operator is equivalent to EXCEPT.

MySQL - The MySQL DBMS doesn't support EXCEPT and INTERSECT. Query translations are needed in both cases.

Adding a Boolean Type

This item proposes adding a BOOLEAN type to std:ADQL.

May 2014 Interop
Requires further discussion - This item was discussed by members of the working group at the May 2014 IVOA Interop meeting.

It was agreed that although making these changes would be a good thing, more work needs to be done on identifying and solving potential compatibility issues before the changes can be included in the std:ADQL standard.

  • It was agreed that BOOLEAN data type would be a useful feature to add
  • It was agreed that changing the return type of CONTAINS() to be a BOOLEAN would make it easier to use
  • It was agreed that making these changes could cause compatibility issues which could not be addressed in a (minor) increment of the std:ADQL standard
  • It was agreed that both of these changes should be considered for a future (major) increment of the std:ADQL standard

Based on the points raised at the May 2014 Interop we would like to split this into two separate proposals and ask for your feedback on each proposal.

Adding a Boolean Type

The first proposal is to add support for a BOOLEAN type to std:ADQL, without changing the return type of CONTAINS().

This would avoid the potential compatibility issues raised at the May 2014 Interop.

The general concensus at the May 2014 Interop was that a BOOLEAN data type would be useful, and that adding it as a new type would not cause compatibility issues.

Community feedback
Name date vote notes
DaveMorris 2014-09-04 +1 Yes to adding BOOLEAN
MarcoMolinaro 2014-09-17 +1  
       

changing the return type of CONTAINS()

The second proposal is to change the return type of CONTAINS().

This is the part that would potentially cause compatibility issues with existing services and clients.

Community feedback
Name date vote notes
DaveMorris 2014-09-04 +1 Yes to changing CONTAINS()
MarcoMolinaro 2014-09-17 +1  
       

Casting to Unit

This item proposes adding a new function IN_UNIT(expr, ) which would convert values in one unit into another.

May 2014 Interop
Requires further discussion - It was agreed that the proposal needs more work done on it before it could included in the std:ADQL standard.

  • It was agreed that scaling conversions would not be difficult to implement
  • It was agreed that conversion between wavelength and frequency would be difficult to implement consistently
  • It was agreed that unit conversions would be most useful in a SELECT list
  • It was agreed that unit conversions would be most difficult to implement in a WHERE clause

Community feedback
Name date vote notes
DaveMorris 2014-09-04 0  
MarcoMolinaro 2014-09-17 0  
       

Column References with UCD Patterns

This item proposes adding a pre-processing macro that locates columns based on their UCD.

May 2014 Interop
Requires further discussion - It was agreed that the proposal needs more work done on it before it could be considered ready to be included in the std:ADQL standard.

Community feedback
Name date vote notes
DaveMorris 2014-09-04 +1 Good idea but needs more work
MarcoMolinaro 2014-09-17 0  
       

Modulo operator

This item proposes adding the modulus operator x % y to the std:ADQL grammar.

May 2014 Interop
Rejected - It was agreed that the benefits of adding the x % y operator syntax were outweighed by cost of compatibility issues caused by adding a new required operator to the std:ADQL grammar.

Community feedback
Name date vote notes
DaveMorris 2014-09-04 +1 Disclosure - this is one of mine and I'm sneaking it back in (see below)
MarcoMolinaro 2014-09-17 +1  
       

If this is the only required operator we are adding, then it is probably not worth the potential compatibility issues.

However, if we are updating the std:ADQL grammar to add UNION, EXCEPT and INTERSECT as operators, does adding the x % y operator cause any additional compatibility issues ? -- DaveMorris - 2014-09-04

Bitwise operators

This item proposes adding support for the AND, OR, XOR and NOT bitwise operations and hexadecimal literals to the [std:ADQL] grammar.

May 2014 Interop
Accepted for next version - It was agreed that hexadecimal literal values should be included in the next (minor) version of the std:ADQL standard.

Accepted for next version - It was agreed that the following functions should be included as an optional feature in the next (minor) version of the std:ADQL standard.

  • BIT_AND(x, y)
  • BIT_OR(x, y)
  • BIT_XOR(x, y)
  • BIT_NOT(x)

Rejected - It was agreed that the benefits of adding the operator, [exp] op [exp], syntax for each operation were outweighed by cost of compatibility issues caused by adding new operators to the std:ADQL grammar.

However, if we are updating the std:ADQL grammar to add UNION, EXCEPT and INTERSECT as operators, does adding the [exp] op [exp] for each of the bitwise operations cause any additional compatibility issues ? -- DaveMorris - 2014-09-04

Community feedback
Name date vote notes
DaveMorris 2014-09-04 +2 Please vote +1 to accept the functions, +2 to accept the operators
MarcoMolinaro 2014-09-17 +1  
       

CAST operator

This item proposes adding a limited form of the CAST operator to the std:ADQL grammar.

This proposal specifically limited the CAST operation to numeric data types only, and excluded CAST to and from character strings.

May 2014 Interop
Accepted for next version - It was agreed that the CAST operator should be including as a required operator in the next (minor) version of the std:ADQL standard.

It was agreed that the set of type conversions should be discussed further, with a view to finalizing the set of conversions supported in the next (minor) version of the [std:ADQL] standard.

Community feedback
Name date vote notes
DaveMorris 2014-09-04 +1  
MarcoMolinaro 2014-09-17 +1  
       

Revision 82014-09-18 - DaveMorris

 
META TOPICPARENT name="DaveMorris"
Notes from the TAP/ADQL splinter session on Wednesday 21 May 2014 at the IVOA Interop meeting at ESAC.

During the meeting the group reviewed a number of proposed changes to TAP and ADQL described in the TAP Implementation Notes Version 1.0.

The following section lists the recommendations agreed at the meeting for each of the changes that were reviewed.

After each section there is a table for adding feedback. Please add your vote to indicate

  • +1 You agree with the decision
  • 0 You don't mind either way
  • -1 You disagree with the decision

If you vote to disagree please provide a brief explanation describing why (or a link to a new page if you prefer).

If you feel that an item needs more discussion please feel free to raise it on the working group mailing list.

Thank you for your feedback. -- DaveMorris - 2014-09-04

Example item

Some text describing the item, with a reference to the original item in the TAP Implementation Notes.

May 2014 Interop
A brief summary of the discussion at the May Interop.

Community feedback
Name date vote notes
MarcoMolinaro 2014-09-04 +1 Yes, good idea
DaveMorris 2014-09-04 0 Ok, as long as it is optional
DaveMorris 2014-09-04 -1 It isn't the right colour, our users prefer blue background.

Separator Nonterminal

This item proposes two options to clarify the use of whitespace and comments in ADQL.

One option for such a clarification is to amend section 2.1 of std:ADQL with a subsection 2.1.4, "Tokens and literals", containing text like the following (taken essentially from std:SQL1992).

  • Any token may be followed by a separator. A nondelimiter token shall be followed by a delimiter token or a separator.

Since the full rules for the separator are somewhat more complex in std:ADQL, an attractive alternative could be to omit the separator nonterminal from the grammar and to just note:

  • Whitespace and comments can occur wherever they can occur in std:SQL1992.

May 2014 Interop
Accepted as errata - It was agreed that this item should be included in the errata note for the current, std:ADQL-20081030, version of the standard.

Community feedback
Name date vote notes
DaveMorris 2014-09-04 +1 Happy with either option
MarcoMolinaro 2014-09-17 +1 Prefer the II solution
       

Type System

This item proposes adding new section to introduce a notion of types into section 2 of the std:ADQL standard.

See original text for details of the proposed type mappings.

[TODO insert table here]

May 2014 Interop
Accepted for next version - It was agreed that this item should be discussed further, with a view to including it in the next (minor) version of the std:ADQL standard.

Community feedback
Name date vote notes
DaveMorris 2014-09-04 +1 Yes, but needs some clarification (see below).
MarcoMolinaro 2014-09-17 +1  
       
Changed:
<
<		Transporting BLOB, TIMESTAMP, POINT and REGION as strings should not imply the ADQL string concatenation operators are applicable.
>
>		Transporting TIMESTAMP, POINT and REGION as strings should not imply the ADQL string concatenation operators are applicable.
 -- DaveMorris - 2014-09-04 (Dave, you mean BLOB or CLOB? -- MarcoMolinaro - 2014-09-17)
Added:
>
>		(Edited to remove BLOB -- DaveMorris - 2014-09-18)
 

Empty Coordinate Systems

This item proposes deprecating the string-valued first argument for the geometry constructors (BOX, CIRCLE, POINT, POLYGON).

May 2014 Interop
Requires further discussion - It was agreed that the proposal needs more work done on it before it could be included in the std:ADQL standard.

Community feedback
Name date vote notes
DaveMorris 2014-09-04 +1  
MarcoMolinaro 2014-09-17 +1  
       

Explanation of optional features

This item proposes adding a section of text to both the std:TAP and std:ADQL specifications that clarifies how optional features are described.

May 2014 Interop
Accepted for next version - It was agreed that this item should be discussed further, with a view to including it in the next (minor) version of the std:ADQL standard.

Community feedback
Name date vote notes
DaveMorris 2014-09-04 +1 I think this is needed
MarcoMolinaro 2014-09-17 +1  
       

Simple Crossmatch Function

This item proposes adding a simple positional crossmatch function to std:ADQL.

May 2014 Interop
Requires further discussion - It was agreed that the proposal needs more work done on it before it could be included in the std:ADQL standard.

  • It was agreed that this would be a useful feature for end users
  • It was noted that adding this feature could be difficult to implement
  • It was noted that part of the rationale for the IVOA services was to implement difficult things on the server side, making things easier for the end user

Community feedback
Name date vote notes
DaveMorris 2014-09-04 +1 Like the idea, needs more work
MarcoMolinaro 2014-09-17 +1  
       

No type-based decay of INTERSECTS

This item proposes deprecating the use of POINT as the first parameter to INTERSECTS.

May 2014 Interop
Accepted for next version - It was agreed that the proposed text should be included in the next (minor) version of the std:ADQL standard.

Community feedback
Name date vote notes
DaveMorris 2014-09-04 +1  
MarcoMolinaro 2014-09-17 +1  
       

Generalized user defined functions

This item proposes allowing user defined functions to return geometric types.

May 2014 Interop
It was agreed that there should be no restriction on the return types of User Defined Functions.

Accepted as errata - It was agreed that this should be included in the errata note for the current, std:ADQL-20081030, version of the standard.

Futher discussion - It was also noted that the SimDAL working group would like to be able to define table value functions in std:ADQL. It was agreed to continue the discussion to find a way of adding support for table value functions in a future version of the std:ADQL standard.

Community feedback
Name date vote notes
DaveMorris 2014-09-04 +1  
MarcoMolinaro 2014-09-17 +1  
       

Case-Insensitive String Comparisons

This item proposes adding functions and operators for to support case-insensitive string comparisons.

May 2014 Interop
Accepted for next version - This item was discussed by members of the working group at the May 2014 IVOA Interop meeting.

It was agreed that the following functions should be included as an optional feature in the next (minor) version of the std:ADQL standard.

  • UPPER
  • LOWER

It was agreed that the following operator should be included as an optional feature in the next (minor) version of the std:ADQL standard.

  • ILIKE

Community feedback
Name date vote notes
DaveMorris 2014-09-04 +1  
MarcoMolinaro 2014-09-17 +1  
       

Set operators

This item proposes adding support for the UNION, EXCEPT and INTERSECT operators.

May 2014 Interop
Accepted for next version - This item was discussed by members of the working group at the May 2014 IVOA Interop meeting.

It was agreed that the following operators should be included as required operators in the next (minor) version of the std:ADQL standard.

  • UNION
  • EXCEPT
  • INTERSECT

It was agreed that the text describing the set operators in the std:ADQL standard should include the following caveats.

  • The set operands MUST produce the same number of columns
  • The corresponding columns in the operands MUST have the same data types
  • The corresponding columns in the operands SHOULD have the same metadata
  • The metadata for the results SHOULD be generated from the left-hand operand

Community feedback
Name date vote notes
DaveMorris 2014-09-04 -1 I agree with the proposal (+1), but we need to confirm which platforms support what operators (see below)
MarcoMolinaro 2014-09-17 +1  
       

The Oracle database platform includes support for UNION and INTERSECT, but not EXCEPT. However, Oracle's MINUS operator appears to be equivalent to EXCEPT.

If we make these operators as a required feature of std:ADQL then it means service implementations based on Oracle will have to parse and translate ADQL queries.

This may not be an issue, but it will be the first time we have (knowingly) added a feature to std:ADQL that requires service implementations to parse and translate ADQL queries.

-- DaveMorris - 2014-09-04

Please contribute your knowledge to the table below to help us build a map of which platforms support which operators.

Vendor version UNION INTERSECT EXCEPT verified by
SQLServer   YES YES YES DaveMorris - 2014-09-04
Sybase          
Oracle   YES YES (see below)  
PostgreSQL   YES YES YES  
MySQL   YES NO NO MarcoMolinaro - 2014-09-17
Derby          
HSQLBD          
SQLLite          

Oracle - The Oracle database platform supports the UNION and INTERSECT, operators directly, and the MINUS operator is equivalent to EXCEPT.

MySQL - The MySQL DBMS doesn't support EXCEPT and INTERSECT. Query translations are needed in both cases.

Adding a Boolean Type

This item proposes adding a BOOLEAN type to std:ADQL.

May 2014 Interop
Requires further discussion - This item was discussed by members of the working group at the May 2014 IVOA Interop meeting.

It was agreed that although making these changes would be a good thing, more work needs to be done on identifying and solving potential compatibility issues before the changes can be included in the std:ADQL standard.

  • It was agreed that BOOLEAN data type would be a useful feature to add
  • It was agreed that changing the return type of CONTAINS() to be a BOOLEAN would make it easier to use
  • It was agreed that making these changes could cause compatibility issues which could not be addressed in a (minor) increment of the std:ADQL standard
  • It was agreed that both of these changes should be considered for a future (major) increment of the std:ADQL standard

Based on the points raised at the May 2014 Interop we would like to split this into two separate proposals and ask for your feedback on each proposal.

Adding a Boolean Type

The first proposal is to add support for a BOOLEAN type to std:ADQL, without changing the return type of CONTAINS().

This would avoid the potential compatibility issues raised at the May 2014 Interop.

The general concensus at the May 2014 Interop was that a BOOLEAN data type would be useful, and that adding it as a new type would not cause compatibility issues.

Community feedback
Name date vote notes
DaveMorris 2014-09-04 +1 Yes to adding BOOLEAN
MarcoMolinaro 2014-09-17 +1  
       

changing the return type of CONTAINS()

The second proposal is to change the return type of CONTAINS().

This is the part that would potentially cause compatibility issues with existing services and clients.

Community feedback
Name date vote notes
DaveMorris 2014-09-04 +1 Yes to changing CONTAINS()
MarcoMolinaro 2014-09-17 +1  
       

Casting to Unit

This item proposes adding a new function IN_UNIT(expr, ) which would convert values in one unit into another.

May 2014 Interop
Requires further discussion - It was agreed that the proposal needs more work done on it before it could included in the std:ADQL standard.

  • It was agreed that scaling conversions would not be difficult to implement
  • It was agreed that conversion between wavelength and frequency would be difficult to implement consistently
  • It was agreed that unit conversions would be most useful in a SELECT list
  • It was agreed that unit conversions would be most difficult to implement in a WHERE clause

Community feedback
Name date vote notes
DaveMorris 2014-09-04 0  
MarcoMolinaro 2014-09-17 0  
       

Column References with UCD Patterns

This item proposes adding a pre-processing macro that locates columns based on their UCD.

May 2014 Interop
Requires further discussion - It was agreed that the proposal needs more work done on it before it could be considered ready to be included in the std:ADQL standard.

Community feedback
Name date vote notes
DaveMorris 2014-09-04 +1 Good idea but needs more work
MarcoMolinaro 2014-09-17 0  
       

Modulo operator

This item proposes adding the modulus operator x % y to the std:ADQL grammar.

May 2014 Interop
Rejected - It was agreed that the benefits of adding the x % y operator syntax were outweighed by cost of compatibility issues caused by adding a new required operator to the std:ADQL grammar.

Community feedback
Name date vote notes
DaveMorris 2014-09-04 +1 Disclosure - this is one of mine and I'm sneaking it back in (see below)
MarcoMolinaro 2014-09-17 +1  
       

If this is the only required operator we are adding, then it is probably not worth the potential compatibility issues.

However, if we are updating the std:ADQL grammar to add UNION, EXCEPT and INTERSECT as operators, does adding the x % y operator cause any additional compatibility issues ? -- DaveMorris - 2014-09-04

Bitwise operators

This item proposes adding support for the AND, OR, XOR and NOT bitwise operations and hexadecimal literals to the [std:ADQL] grammar.

May 2014 Interop
Accepted for next version - It was agreed that hexadecimal literal values should be included in the next (minor) version of the std:ADQL standard.

Accepted for next version - It was agreed that the following functions should be included as an optional feature in the next (minor) version of the std:ADQL standard.

  • BIT_AND(x, y)
  • BIT_OR(x, y)
  • BIT_XOR(x, y)
  • BIT_NOT(x)

Rejected - It was agreed that the benefits of adding the operator, [exp] op [exp], syntax for each operation were outweighed by cost of compatibility issues caused by adding new operators to the std:ADQL grammar.

However, if we are updating the std:ADQL grammar to add UNION, EXCEPT and INTERSECT as operators, does adding the [exp] op [exp] for each of the bitwise operations cause any additional compatibility issues ? -- DaveMorris - 2014-09-04

Community feedback
Name date vote notes
DaveMorris 2014-09-04 +2 Please vote +1 to accept the functions, +2 to accept the operators
MarcoMolinaro 2014-09-17 +1  
       

CAST operator

This item proposes adding a limited form of the CAST operator to the std:ADQL grammar.

This proposal specifically limited the CAST operation to numeric data types only, and excluded CAST to and from character strings.

May 2014 Interop
Accepted for next version - It was agreed that the CAST operator should be including as a required operator in the next (minor) version of the std:ADQL standard.

It was agreed that the set of type conversions should be discussed further, with a view to finalizing the set of conversions supported in the next (minor) version of the [std:ADQL] standard.

Community feedback
Name date vote notes
DaveMorris 2014-09-04 +1  
MarcoMolinaro 2014-09-17 +1  
       

Revision 72014-09-17 - MarcoMolinaro

 
META TOPICPARENT name="DaveMorris"
Notes from the TAP/ADQL splinter session on Wednesday 21 May 2014 at the IVOA Interop meeting at ESAC.

During the meeting the group reviewed a number of proposed changes to TAP and ADQL described in the TAP Implementation Notes Version 1.0.

The following section lists the recommendations agreed at the meeting for each of the changes that were reviewed.

After each section there is a table for adding feedback. Please add your vote to indicate

  • +1 You agree with the decision
  • 0 You don't mind either way
  • -1 You disagree with the decision

If you vote to disagree please provide a brief explanation describing why (or a link to a new page if you prefer).

If you feel that an item needs more discussion please feel free to raise it on the working group mailing list.

Thank you for your feedback. -- DaveMorris - 2014-09-04

Example item

Some text describing the item, with a reference to the original item in the TAP Implementation Notes.

May 2014 Interop
A brief summary of the discussion at the May Interop.

Community feedback
Name date vote notes
MarcoMolinaro 2014-09-04 +1 Yes, good idea
DaveMorris 2014-09-04 0 Ok, as long as it is optional
DaveMorris 2014-09-04 -1 It isn't the right colour, our users prefer blue background.

Separator Nonterminal

This item proposes two options to clarify the use of whitespace and comments in ADQL.

One option for such a clarification is to amend section 2.1 of std:ADQL with a subsection 2.1.4, "Tokens and literals", containing text like the following (taken essentially from std:SQL1992).

  • Any token may be followed by a separator. A nondelimiter token shall be followed by a delimiter token or a separator.

Since the full rules for the separator are somewhat more complex in std:ADQL, an attractive alternative could be to omit the separator nonterminal from the grammar and to just note:

  • Whitespace and comments can occur wherever they can occur in std:SQL1992.

May 2014 Interop
Accepted as errata - It was agreed that this item should be included in the errata note for the current, std:ADQL-20081030, version of the standard.

Community feedback
Name date vote notes
DaveMorris 2014-09-04 +1 Happy with either option
Added:
>
>
MarcoMolinaro 2014-09-17 +1 Prefer the II solution
 
       

Type System

This item proposes adding new section to introduce a notion of types into section 2 of the std:ADQL standard.

See original text for details of the proposed type mappings.

[TODO insert table here]

May 2014 Interop
Accepted for next version - It was agreed that this item should be discussed further, with a view to including it in the next (minor) version of the std:ADQL standard.

Community feedback
Name date vote notes
DaveMorris 2014-09-04 +1 Yes, but needs some clarification (see below).
Added:
>
>
MarcoMolinaro 2014-09-17 +1  
 
       

Transporting BLOB, TIMESTAMP, POINT and REGION as strings should not imply the ADQL string concatenation operators are applicable. -- DaveMorris - 2014-09-04

Added:
>
>		(Dave, you mean BLOB or CLOB? -- MarcoMolinaro - 2014-09-17)
 

Empty Coordinate Systems

This item proposes deprecating the string-valued first argument for the geometry constructors (BOX, CIRCLE, POINT, POLYGON).

May 2014 Interop
Requires further discussion - It was agreed that the proposal needs more work done on it before it could be included in the std:ADQL standard.

Community feedback
Name date vote notes
DaveMorris 2014-09-04 +1  
Added:
>
>
MarcoMolinaro 2014-09-17 +1  
 
       

Explanation of optional features

This item proposes adding a section of text to both the std:TAP and std:ADQL specifications that clarifies how optional features are described.

May 2014 Interop
Accepted for next version - It was agreed that this item should be discussed further, with a view to including it in the next (minor) version of the std:ADQL standard.

Community feedback
Name date vote notes
DaveMorris 2014-09-04 +1 I think this is needed
Added:
>
>
MarcoMolinaro 2014-09-17 +1  
 
       

Simple Crossmatch Function

This item proposes adding a simple positional crossmatch function to std:ADQL.

May 2014 Interop
Requires further discussion - It was agreed that the proposal needs more work done on it before it could be included in the std:ADQL standard.

  • It was agreed that this would be a useful feature for end users
  • It was noted that adding this feature could be difficult to implement
  • It was noted that part of the rationale for the IVOA services was to implement difficult things on the server side, making things easier for the end user

Community feedback
Name date vote notes
DaveMorris 2014-09-04 +1 Like the idea, needs more work
Added:
>
>
MarcoMolinaro 2014-09-17 +1  
 
       

No type-based decay of INTERSECTS

This item proposes deprecating the use of POINT as the first parameter to INTERSECTS.

May 2014 Interop
Accepted for next version - It was agreed that the proposed text should be included in the next (minor) version of the std:ADQL standard.

Community feedback
Name date vote notes
DaveMorris 2014-09-04 +1  
Added:
>
>
MarcoMolinaro 2014-09-17 +1  
 
       

Generalized user defined functions

This item proposes allowing user defined functions to return geometric types.

May 2014 Interop
It was agreed that there should be no restriction on the return types of User Defined Functions.

Accepted as errata - It was agreed that this should be included in the errata note for the current, std:ADQL-20081030, version of the standard.

Futher discussion - It was also noted that the SimDAL working group would like to be able to define table value functions in std:ADQL. It was agreed to continue the discussion to find a way of adding support for table value functions in a future version of the std:ADQL standard.

Community feedback
Name date vote notes
DaveMorris 2014-09-04 +1  
Added:
>
>
MarcoMolinaro 2014-09-17 +1  
 
       

Case-Insensitive String Comparisons

This item proposes adding functions and operators for to support case-insensitive string comparisons.

May 2014 Interop
Accepted for next version - This item was discussed by members of the working group at the May 2014 IVOA Interop meeting.

It was agreed that the following functions should be included as an optional feature in the next (minor) version of the std:ADQL standard.

  • UPPER
  • LOWER

It was agreed that the following operator should be included as an optional feature in the next (minor) version of the std:ADQL standard.

  • ILIKE

Community feedback
Name date vote notes
DaveMorris 2014-09-04 +1  
Added:
>
>
MarcoMolinaro 2014-09-17 +1  
 
       

Set operators

This item proposes adding support for the UNION, EXCEPT and INTERSECT operators.

May 2014 Interop
Accepted for next version - This item was discussed by members of the working group at the May 2014 IVOA Interop meeting.

It was agreed that the following operators should be included as required operators in the next (minor) version of the std:ADQL standard.

  • UNION
  • EXCEPT
  • INTERSECT

It was agreed that the text describing the set operators in the std:ADQL standard should include the following caveats.

  • The set operands MUST produce the same number of columns
  • The corresponding columns in the operands MUST have the same data types
  • The corresponding columns in the operands SHOULD have the same metadata
  • The metadata for the results SHOULD be generated from the left-hand operand

Community feedback
Name date vote notes
DaveMorris 2014-09-04 -1 I agree with the proposal (+1), but we need to confirm which platforms support what operators (see below)
Added:
>
>
MarcoMolinaro 2014-09-17 +1  
 
       

The Oracle database platform includes support for UNION and INTERSECT, but not EXCEPT. However, Oracle's MINUS operator appears to be equivalent to EXCEPT.

If we make these operators as a required feature of std:ADQL then it means service implementations based on Oracle will have to parse and translate ADQL queries.

This may not be an issue, but it will be the first time we have (knowingly) added a feature to std:ADQL that requires service implementations to parse and translate ADQL queries.

-- DaveMorris - 2014-09-04

Please contribute your knowledge to the table below to help us build a map of which platforms support which operators.

Vendor version UNION INTERSECT EXCEPT verified by
SQLServer   YES YES YES DaveMorris - 2014-09-04
Sybase          
Oracle   YES YES (see below)  
PostgreSQL   YES YES YES  
Changed:
<
<
MySQL          
>
>
MySQL   YES NO NO MarcoMolinaro - 2014-09-17
 
Derby          
HSQLBD          
SQLLite          

Oracle - The Oracle database platform supports the UNION and INTERSECT, operators directly, and the MINUS operator is equivalent to EXCEPT.

Added:
>
>		MySQL - The MySQL DBMS doesn't support EXCEPT and INTERSECT. Query translations are needed in both cases.
 

Adding a Boolean Type

This item proposes adding a BOOLEAN type to std:ADQL.

May 2014 Interop
Requires further discussion - This item was discussed by members of the working group at the May 2014 IVOA Interop meeting.

It was agreed that although making these changes would be a good thing, more work needs to be done on identifying and solving potential compatibility issues before the changes can be included in the std:ADQL standard.

  • It was agreed that BOOLEAN data type would be a useful feature to add
  • It was agreed that changing the return type of CONTAINS() to be a BOOLEAN would make it easier to use
  • It was agreed that making these changes could cause compatibility issues which could not be addressed in a (minor) increment of the std:ADQL standard
  • It was agreed that both of these changes should be considered for a future (major) increment of the std:ADQL standard

Based on the points raised at the May 2014 Interop we would like to split this into two separate proposals and ask for your feedback on each proposal.

Adding a Boolean Type

The first proposal is to add support for a BOOLEAN type to std:ADQL, without changing the return type of CONTAINS().

This would avoid the potential compatibility issues raised at the May 2014 Interop.

The general concensus at the May 2014 Interop was that a BOOLEAN data type would be useful, and that adding it as a new type would not cause compatibility issues.

Community feedback
Name date vote notes
DaveMorris 2014-09-04 +1 Yes to adding BOOLEAN
Added:
>
>
MarcoMolinaro 2014-09-17 +1  
 
       

changing the return type of CONTAINS()

The second proposal is to change the return type of CONTAINS().

This is the part that would potentially cause compatibility issues with existing services and clients.

Community feedback
Name date vote notes
DaveMorris 2014-09-04 +1 Yes to changing CONTAINS()
Added:
>
>
MarcoMolinaro 2014-09-17 +1  
 
       

Casting to Unit

This item proposes adding a new function IN_UNIT(expr, ) which would convert values in one unit into another.

May 2014 Interop
Requires further discussion - It was agreed that the proposal needs more work done on it before it could included in the std:ADQL standard.

  • It was agreed that scaling conversions would not be difficult to implement
  • It was agreed that conversion between wavelength and frequency would be difficult to implement consistently
  • It was agreed that unit conversions would be most useful in a SELECT list
  • It was agreed that unit conversions would be most difficult to implement in a WHERE clause

Community feedback
Name date vote notes
DaveMorris 2014-09-04 0  
Added:
>
>
MarcoMolinaro 2014-09-17 0  
 
       

Column References with UCD Patterns

This item proposes adding a pre-processing macro that locates columns based on their UCD.

May 2014 Interop
Requires further discussion - It was agreed that the proposal needs more work done on it before it could be considered ready to be included in the std:ADQL standard.

Community feedback
Name date vote notes
DaveMorris 2014-09-04 +1 Good idea but needs more work
Added:
>
>
MarcoMolinaro 2014-09-17 0  
 
       

Modulo operator

This item proposes adding the modulus operator x % y to the std:ADQL grammar.

May 2014 Interop
Rejected - It was agreed that the benefits of adding the x % y operator syntax were outweighed by cost of compatibility issues caused by adding a new required operator to the std:ADQL grammar.

Community feedback
Name date vote notes
DaveMorris 2014-09-04 +1 Disclosure - this is one of mine and I'm sneaking it back in (see below)
Added:
>
>
MarcoMolinaro 2014-09-17 +1  
 
       

If this is the only required operator we are adding, then it is probably not worth the potential compatibility issues.

However, if we are updating the std:ADQL grammar to add UNION, EXCEPT and INTERSECT as operators, does adding the x % y operator cause any additional compatibility issues ? -- DaveMorris - 2014-09-04

Bitwise operators

This item proposes adding support for the AND, OR, XOR and NOT bitwise operations and hexadecimal literals to the [std:ADQL] grammar.

May 2014 Interop
Accepted for next version - It was agreed that hexadecimal literal values should be included in the next (minor) version of the std:ADQL standard.

Accepted for next version - It was agreed that the following functions should be included as an optional feature in the next (minor) version of the std:ADQL standard.

  • BIT_AND(x, y)
  • BIT_OR(x, y)
  • BIT_XOR(x, y)
  • BIT_NOT(x)

Rejected - It was agreed that the benefits of adding the operator, [exp] op [exp], syntax for each operation were outweighed by cost of compatibility issues caused by adding new operators to the std:ADQL grammar.

However, if we are updating the std:ADQL grammar to add UNION, EXCEPT and INTERSECT as operators, does adding the [exp] op [exp] for each of the bitwise operations cause any additional compatibility issues ? -- DaveMorris - 2014-09-04

Community feedback
Name date vote notes
DaveMorris 2014-09-04 +2 Please vote +1 to accept the functions, +2 to accept the operators
Added:
>
>
MarcoMolinaro 2014-09-17 +1  
 
       

CAST operator

This item proposes adding a limited form of the CAST operator to the std:ADQL grammar.

This proposal specifically limited the CAST operation to numeric data types only, and excluded CAST to and from character strings.

May 2014 Interop
Accepted for next version - It was agreed that the CAST operator should be including as a required operator in the next (minor) version of the std:ADQL standard.

It was agreed that the set of type conversions should be discussed further, with a view to finalizing the set of conversions supported in the next (minor) version of the [std:ADQL] standard.

Community feedback
Name date vote notes
DaveMorris 2014-09-04 +1  
Added:
>
>
MarcoMolinaro 2014-09-17 +1  
 
       

Revision 62014-09-04 - DaveMorris

 
META TOPICPARENT name="DaveMorris"
Notes from the TAP/ADQL splinter session on Wednesday 21 May 2014 at the IVOA Interop meeting at ESAC.

During the meeting the group reviewed a number of proposed changes to TAP and ADQL described in the TAP Implementation Notes Version 1.0.

The following section lists the recommendations agreed at the meeting for each of the changes that were reviewed.

After each section there is a table for adding feedback. Please add your vote to indicate

  • +1 You agree with the decision
  • 0 You don't mind either way
  • -1 You disagree with the decision
Deleted:
<
<		If you vote to disagree please provide a brief one line explanation describing why (or a link to a new page if you prefer).
 
Changed:
<
<		For items that need more discussion please raise them on the working group mailing list.
>
>		If you vote to disagree please provide a brief explanation describing why (or a link to a new page if you prefer).
 
Changed:
<
<		Thank you for your feedback. -- DaveMorris - 2014-07-18
>
>		If you feel that an item needs more discussion please feel free to raise it on the working group mailing list.
 
Added:
>
>		Thank you for your feedback. -- DaveMorris - 2014-09-04
 

Example item

Changed:
<
<		Some text describing the item, with a reference to the original item in the TAP Implementation Notes.
>
>		Some text describing the item, with a reference to the original item in the TAP Implementation Notes.
 
May 2014 Interop
A brief summary of the discussion at the May Interop.

Community feedback
Name date vote notes
Changed:
<
<
MarcoMolinaro 2014-07-18 +1  
DaveMorris 2014-07-18 +1 Yes, good idea
DaveMorris 2014-07-18 0 Ok, as long as it is optional
>
>
MarcoMolinaro 2014-09-04 +1 Yes, good idea
DaveMorris 2014-09-04 0 Ok, as long as it is optional
DaveMorris 2014-09-04 -1 It isn't the right colour, our users prefer blue background.
Deleted:
<
<
DaveMorris 2014-07-18 -1 It isn't the right colour, our users prefer blue background.
 

Separator Nonterminal

This item proposes two options to clarify the use of whitespace and comments in ADQL.
Changed:
<
<		One option for such a clarification is to amend section 2.1 of [std:ADQL] with a subsection 2.1.4, "Tokens and literals", containing text like the following (taken essentially from [std:SQL1992]).
>
>		One option for such a clarification is to amend section 2.1 of std:ADQL with a subsection 2.1.4, "Tokens and literals", containing text like the following (taken essentially from std:SQL1992).
 
Changed:
<
<
  1. Any token may be followed by a separator. A nondelimiter token shall be followed by a delimiter token or a separator.
>
>
  • Any token may be followed by a separator. A nondelimiter token shall be followed by a delimiter token or a separator.
 
Changed:
<
<		Since the full rules for the separator are somewhat more complex in [std:ADQL], an attractive alternative could be to omit the separator nonterminal from the grammar and to just note:
>
>		Since the full rules for the separator are somewhat more complex in std:ADQL, an attractive alternative could be to omit the separator nonterminal from the grammar and to just note:
 
Changed:
<
<
  1. Whitespace and comments can occur wherever they can occur in [std:SQL1992].
>
>
  • Whitespace and comments can occur wherever they can occur in std:SQL1992.
 
May 2014 Interop
Accepted as errata -
Changed:
<
<		It was agreed that this item should be included in the errata note for the current, [std:ADQL-20081030], version of the standard.
>
>		It was agreed that this item should be included in the errata note for the current, std:ADQL-20081030, version of the standard.
 
Community feedback
Name date vote notes
Changed:
<
<
DaveMorris 2014-07-18 0 Accept either option
>
>
DaveMorris 2014-09-04 +1 Happy with either option
 
       

Type System

Changed:
<
<		This item proposes adding new section to introduce a notion of types into section 2 of the ADQL recommendation.
>
>		This item proposes adding new section to introduce a notion of types into section 2 of the std:ADQL standard.
  See original text for details of the proposed type mappings.

[TODO insert table here]

May 2014 Interop
Changed:
<
<		Accepted for next version - It was agreed that this item should be discussed further, with a view to including it in the next (minor) version of the [std:ADQL] standard.
>
>		Accepted for next version - It was agreed that this item should be discussed further, with a view to including it in the next (minor) version of the std:ADQL standard.
 
Community feedback
Name date vote notes
Changed:
<
<
DaveMorris 2014-07-18 -1 In general yes, but some parts need further discussion (see below).
>
>
DaveMorris 2014-09-04 +1 Yes, but needs some clarification (see below).
 
       
Changed:
<
<		Transporting BLOB, CLOB, TIMESTAMP, POINT and REGION as char() strings should *not imply the ADQL string concatenation operator are applicable.
>
>		Transporting BLOB, TIMESTAMP, POINT and REGION as strings should not imply the ADQL string concatenation operators are applicable.
 -- DaveMorris - 2014-09-04

Empty Coordinate Systems

This item proposes
Changed:
<
<		deprecating the string-valued first argument for the geometry constructors (BOX, CIRCLE, POINT, POLYGON).
>
>		deprecating the string-valued first argument for the geometry constructors (BOX, CIRCLE, POINT, POLYGON).
 
May 2014 Interop
Changed:
<
<		Requires further discussion - It was agreed that the proposal needs more work done on it before it could be included in the [std:ADQL] standard.
>
>		Requires further discussion - It was agreed that the proposal needs more work done on it before it could be included in the std:ADQL standard.
 
Community feedback
Name date vote notes
Changed:
<
<
DaveMorris 2014-07-18 +1  
>
>
DaveMorris 2014-09-04 +1  
 
       

Explanation of optional features

This item proposes
Changed:
<
<		adding a section of text to both the [std:TAP] and [std:ADQL] specifications that clarifies how optional features are described.
>
>		adding a section of text to both the std:TAP and std:ADQL specifications that clarifies how optional features are described.
 
May 2014 Interop
Changed:
<
<		Accepted for next version -
>
>		Accepted for next version -
 It was agreed that this item should be discussed further, with a view to including it in the
Changed:
<
<		next (minor) version of the [std:ADQL] standard.
>
>		next (minor) version of the std:ADQL standard.
 
Community feedback
Name date vote notes
Changed:
<
<
DaveMorris 2014-07-18 +1 I think this is needed
>
>
DaveMorris 2014-09-04 +1 I think this is needed
 
       

Simple Crossmatch Function

This item proposes
Changed:
<
<		adding a simple positional crossmatch function to [std:ADQL].
>
>		adding a simple positional crossmatch function to std:ADQL.
 
May 2014 Interop
Changed:
<
<		Requires further discussion - It was agreed that the proposal needs more work done on it before it could be included in the [std:ADQL] standard.
>
>		Requires further discussion - It was agreed that the proposal needs more work done on it before it could be included in the std:ADQL standard.
Added:
>
>
 
  • It was agreed that this would be a useful feature for end users
  • It was noted that adding this feature could be difficult to implement
  • It was noted that part of the rationale for the IVOA services was to implement difficult things on the server side, making things easier for the end user

Community feedback
Name date vote notes
Changed:
<
<
DaveMorris 2014-07-18 0 Like the idea, needs more work
>
>
DaveMorris 2014-09-04 +1 Like the idea, needs more work
 
       

No type-based decay of INTERSECTS

This item proposes deprecating the use of POINT as the first parameter to INTERSECTS.

May 2014 Interop
Changed:
<
<		Accepted for next version - It was agreed that the proposed text should be included in the next (minor) version of the std:ADQL standard.
>
>		Accepted for next version - It was agreed that the proposed text should be included in the next (minor) version of the std:ADQL standard.
 
Community feedback
Name date vote notes
Changed:
<
<
DaveMorris 2014-07-18 +1  
>
>
DaveMorris 2014-09-04 +1  
 
       

Generalized user defined functions

This item proposes allowing user defined functions to return geometric types.

May 2014 Interop
Deleted:
<
<		Accepted as errata -
 It was agreed that there should be no restriction on the return types of User Defined Functions.
Deleted:
<
<		It was agreed that this should be included in the errata note for the current, [std:ADQL-20081030], version of the standard.
 
Added:
>
>		Accepted as errata - It was agreed that this should be included in the errata note for the current, std:ADQL-20081030, version of the standard.
 Futher discussion -
Changed:
<
<		It was also noted that the SimDAl working group would like to be able to define table value functions in std:ADQL. It was agreed to continue the discussion to find a way of adding support for table value functions in a future version of the std:ADQL standard.
>
>		It was also noted that the SimDAL working group would like to be able to define table value functions in std:ADQL. It was agreed to continue the discussion to find a way of adding support for table value functions in a future version of the std:ADQL standard.
 
Community feedback
Name date vote notes
Changed:
<
<
DaveMorris 2014-07-18 +1  
>
>
DaveMorris 2014-09-04 +1  
 
       

Case-Insensitive String Comparisons

This item proposes adding functions and operators for to support case-insensitive string comparisons.

May 2014 Interop
Changed:
<
<		Accepted for next version -
>
>		Accepted for next version -
 This item was discussed by members of the working group at the May 2014 IVOA Interop meeting.
Changed:
<
<		It was agreed that the following functions should be included as an optional feature in the next (minor) version of the std:ADQL standard.
>
>		It was agreed that the following functions should be included as an optional feature in the next (minor) version of the std:ADQL standard.
 
  • UPPER
  • LOWER
Changed:
<
<		It was agreed that the following operator should be included as an optional feature in the next (minor) version of the std:ADQL standard.
>
>		It was agreed that the following operator should be included as an optional feature in the next (minor) version of the std:ADQL standard.
 
  • ILIKE

Community feedback
Name date vote notes
Changed:
<
<
DaveMorris 2014-07-18 +1  
>
>
DaveMorris 2014-09-04 +1  
 
       

Set operators

This item proposes adding support for the UNION, EXCEPT and INTERSECT operators.

May 2014 Interop
Changed:
<
<		Accepted for next version -
>
>		Accepted for next version -
 This item was discussed by members of the working group at the May 2014 IVOA Interop meeting.
Changed:
<
<		It was agreed that the following operators should be included in the next (minor) version of the std:ADQL standard.
>
>		It was agreed that the following operators should be included as required operators in the next (minor) version of the std:ADQL standard.
 
  • UNION
  • EXCEPT
  • INTERSECT
Changed:
<
<		It was agreed that the text describing the set operators in the std:ADQL standard should include the following caveats.
>
>		It was agreed that the text describing the set operators in the std:ADQL standard should include the following caveats.
 
  • The set operands MUST produce the same number of columns
  • The corresponding columns in the operands MUST have the same data types
  • The corresponding columns in the operands SHOULD have the same metadata
  • The metadata for the results SHOULD be generated from the left-hand operand

Community feedback
Name date vote notes
Changed:
<
<
DaveMorris 2014-07-18 -1 I agree with the proposal (+1), but we need to confirm which platforms support what operators (see below)
>
>
DaveMorris 2014-09-04 -1 I agree with the proposal (+1), but we need to confirm which platforms support what operators (see below)
 
       

The Oracle database platform includes support for UNION and INTERSECT, but not EXCEPT.

Changed:
<
<		However, Oracle's MINUS opperator appears to be equivalent to EXCEPT.
>
>		However, Oracle's MINUS operator appears to be equivalent to EXCEPT.
 
Changed:
<
<		If we make these operators as a required feature of std:ADQL then it means service implementatiuons based on Oracle will have to
>
>		If we make these operators as a required feature of std:ADQL then it means service implementations based on Oracle will have to
 parse and translate ADQL queries.

This may not be an issue, but it will be the first time we have (knowingly) added

Changed:
<
<		a feature to std:ADQL that requires service implementatiuons to
>
>		a feature to std:ADQL that requires service implementations to
 parse and translate ADQL queries.

-- DaveMorris - 2014-09-04

Changed:
<
<		Please cotribute your knowledge to the table below to help us build a map of which
>
>		Please contribute your knowledge to the table below to help us build a map of which
 platforms support which operators.

Vendor version UNION INTERSECT EXCEPT verified by
Changed:
<
<
SQLServer   YES YES YES DaveMorris - 2014-09-04
Sybase        
Oracle   YES YES equivalent MINUS
PostgreSQL   YES YES YES DaveMorris - 2014-09-04
MySQL        
Derby        
HSQLBD        
SQLLite        
>
>
SQLServer   YES YES YES DaveMorris - 2014-09-04
Sybase          
Oracle   YES YES (see below)  
PostgreSQL   YES YES YES  
MySQL          
Derby          
HSQLBD          
SQLLite          
Added:
>
>		 Oracle - The Oracle database platform supports the UNION and INTERSECT, operators directly, and the MINUS operator is equivalent to EXCEPT.

Adding a Boolean Type

This item proposes adding a BOOLEAN type to std:ADQL.

May 2014 Interop
Requires further discussion - This item was discussed by members of the working group at the May 2014 IVOA Interop meeting.

It was agreed that although making these changes would be a good thing, more work needs to be done on identifying and solving potential compatibility issues before the changes can be included in the std:ADQL standard.

  • It was agreed that BOOLEAN data type would be a useful feature to add
  • It was agreed that changing the return type of CONTAINS() to be a BOOLEAN would make it easier to use
  • It was agreed that making these changes could cause compatibility issues which could not be addressed in a (minor) increment of the std:ADQL standard
  • It was agreed that both of these changes should be considered for a future (major) increment of the std:ADQL standard

Based on the points raised at the May 2014 Interop we would like to split this into two separate proposals and ask for your feedback on each proposal.

Adding a Boolean Type

The first proposal is to add support for a BOOLEAN type to std:ADQL, without changing the return type of CONTAINS().

This would avoid the potential compatibility issues raised at the May 2014 Interop.

The general concensus at the May 2014 Interop was that a BOOLEAN data type would be useful, and that adding it as a new type would not cause compatibility issues.

Community feedback
Name date vote notes
DaveMorris 2014-09-04 +1 Yes to adding BOOLEAN
       

changing the return type of CONTAINS()

The second proposal is to change the return type of CONTAINS().

This is the part that would potentially cause compatibility issues with existing services and clients.

Community feedback
Name date vote notes
DaveMorris 2014-09-04 +1 Yes to changing CONTAINS()
       

Casting to Unit

This item proposes adding a new function IN_UNIT(expr, ) which would convert values in one unit into another.

May 2014 Interop
Requires further discussion - It was agreed that the proposal needs more work done on it before it could included in the std:ADQL standard.

  • It was agreed that scaling conversions would not be difficult to implement
  • It was agreed that conversion between wavelength and frequency would be difficult to implement consistently
  • It was agreed that unit conversions would be most useful in a SELECT list
  • It was agreed that unit conversions would be most difficult to implement in a WHERE clause

Community feedback
Name date vote notes
DaveMorris 2014-09-04 0  
       

Column References with UCD Patterns

This item proposes adding a pre-processing macro that locates columns based on their UCD.

May 2014 Interop
Requires further discussion - It was agreed that the proposal needs more work done on it before it could be considered ready to be included in the std:ADQL standard.

Community feedback
Name date vote notes
DaveMorris 2014-09-04 +1 Good idea but needs more work
       

Modulo operator

This item proposes adding the modulus operator x % y to the std:ADQL grammar.

May 2014 Interop
Rejected - It was agreed that the benefits of adding the x % y operator syntax were outweighed by cost of compatibility issues caused by adding a new required operator to the std:ADQL grammar.

Community feedback
Name date vote notes
DaveMorris 2014-09-04 +1 Disclosure - this is one of mine and I'm sneaking it back in (see below)
       

If this is the only required operator we are adding, then it is probably not worth the potential compatibility issues.

However, if we are updating the std:ADQL grammar to add UNION, EXCEPT and INTERSECT as operators, does adding the x % y operator cause any additional compatibility issues ? -- DaveMorris - 2014-09-04

Bitwise operators

This item proposes adding support for the AND, OR, XOR and NOT bitwise operations and hexadecimal literals to the [std:ADQL] grammar.

May 2014 Interop
Accepted for next version - It was agreed that hexadecimal literal values should be included in the next (minor) version of the std:ADQL standard.

Accepted for next version - It was agreed that the following functions should be included as an optional feature in the next (minor) version of the std:ADQL standard.

  • BIT_AND(x, y)
  • BIT_OR(x, y)
  • BIT_XOR(x, y)
  • BIT_NOT(x)

Rejected - It was agreed that the benefits of adding the operator, [exp] op [exp], syntax for each operation were outweighed by cost of compatibility issues caused by adding new operators to the std:ADQL grammar.

However, if we are updating the std:ADQL grammar to add UNION, EXCEPT and INTERSECT as operators, does adding the [exp] op [exp] for each of the bitwise operations cause any additional compatibility issues ? -- DaveMorris - 2014-09-04

Community feedback
Name date vote notes
DaveMorris 2014-09-04 +2 Please vote +1 to accept the functions, +2 to accept the operators
       

CAST operator

This item proposes adding a limited form of the CAST operator to the std:ADQL grammar.

This proposal specifically limited the CAST operation to numeric data types only, and excluded CAST to and from character strings.

May 2014 Interop
Accepted for next version - It was agreed that the CAST operator should be including as a required operator in the next (minor) version of the std:ADQL standard.

It was agreed that the set of type conversions should be discussed further, with a view to finalizing the set of conversions supported in the next (minor) version of the [std:ADQL] standard.

Community feedback
Name date vote notes
DaveMorris 2014-09-04 +1  
       

Revision 52014-09-04 - DaveMorris

 
META TOPICPARENT name="DaveMorris"
Notes from the TAP/ADQL splinter session on Wednesday 21 May 2014 at the IVOA Interop meeting at ESAC.

During the meeting the group reviewed a number of proposed changes to TAP and ADQL described in the TAP Implementation Notes Version 1.0.

The following section lists the recommendations agreed at the meeting for each of the changes that were reviewed.

After each section there is a table for adding feedback. Please add your vote to indicate

  • +1 You agree with the decision
  • 0 You don't mind either way
  • -1 You disagree with the decision
If you vote to disagree please provide a brief one line explanation describing why (or a link to a new page if you prefer).

For items that need more discussion please raise them on the working group mailing list.

Thank you for your feedback. -- DaveMorris - 2014-07-18

Example item

Some text describing the item, with a reference to the original item in the TAP Implementation Notes.

May 2014 Interop
A brief summary of the discussion at the May Interop.

Community feedback
Name date vote notes
MarcoMolinaro 2014-07-18 +1  
DaveMorris 2014-07-18 +1 Yes, good idea
DaveMorris 2014-07-18 0 Ok, as long as it is optional
DaveMorris 2014-07-18 -1 It isn't the right colour, our users prefer blue background.

Separator Nonterminal

This item proposes two options to clarify the use of whitespace and comments in ADQL.

One option for such a clarification is to amend section 2.1 of [std:ADQL] with a subsection 2.1.4, "Tokens and literals", containing text like the following (taken essentially from [std:SQL1992]).

  1. Any token may be followed by a separator. A nondelimiter token shall be followed by a delimiter token or a separator.

Since the full rules for the separator are somewhat more complex in [std:ADQL], an attractive alternative could be to omit the separator nonterminal from the grammar and to just note:

  1. Whitespace and comments can occur wherever they can occur in [std:SQL1992].

May 2014 Interop
Added:
>
>		Accepted as errata -
 It was agreed that this item should be included in the errata note for the current, [std:ADQL-20081030], version of the standard.

Community feedback
Name date vote notes
DaveMorris 2014-07-18 0 Accept either option
Added:
>
>
       
 

Type System

This item proposes adding new section to introduce a notion of types into section 2 of the ADQL recommendation.
Changed:
<
<		See the original text for details of the proposed type mappings.
>
>		See original text for details of the proposed type mappings.
 
Added:
>
>		[TODO insert table here]
 
May 2014 Interop
Added:
>
>		Accepted for next version -
 It was agreed that this item should be discussed further, with a view to including it in the next (minor) version of the [std:ADQL] standard.

Community feedback
Name date vote notes
DaveMorris 2014-07-18 -1 In general yes, but some parts need further discussion (see below).
Added:
>
>
       
 
Changed:
<
<		Transporting BLOB, CLOB, TIMESTAMP, POINT and REGION as char(*) strings should not imply the ADQL string concatenation operator are applicable.
>
>		Transporting BLOB, CLOB, TIMESTAMP, POINT and REGION as char() strings should *not imply the ADQL string concatenation operator are applicable.
 -- DaveMorris - 2014-09-04
Added:
>
>

Empty Coordinate Systems

This item proposes deprecating the string-valued first argument for the geometry constructors (BOX, CIRCLE, POINT, POLYGON).

May 2014 Interop
Requires further discussion - It was agreed that the proposal needs more work done on it before it could be included in the [std:ADQL] standard.

Community feedback
Name date vote notes
DaveMorris 2014-07-18 +1  
       

Explanation of optional features

This item proposes adding a section of text to both the [std:TAP] and [std:ADQL] specifications that clarifies how optional features are described.

May 2014 Interop
Accepted for next version - It was agreed that this item should be discussed further, with a view to including it in the next (minor) version of the [std:ADQL] standard.

Community feedback
Name date vote notes
DaveMorris 2014-07-18 +1 I think this is needed
       

Simple Crossmatch Function

This item proposes adding a simple positional crossmatch function to [std:ADQL].

May 2014 Interop
Requires further discussion - It was agreed that the proposal needs more work done on it before it could be included in the [std:ADQL] standard.
  • It was agreed that this would be a useful feature for end users
  • It was noted that adding this feature could be difficult to implement
  • It was noted that part of the rationale for the IVOA services was to implement difficult things on the server side, making things easier for the end user

Community feedback
Name date vote notes
DaveMorris 2014-07-18 0 Like the idea, needs more work
       

No type-based decay of INTERSECTS

This item proposes deprecating the use of POINT as the first parameter to INTERSECTS.

May 2014 Interop
Accepted for next version - It was agreed that the proposed text should be included in the next (minor) version of the std:ADQL standard.

Community feedback
Name date vote notes
DaveMorris 2014-07-18 +1  
       

Generalized user defined functions

This item proposes allowing user defined functions to return geometric types.

May 2014 Interop
Accepted as errata - It was agreed that there should be no restriction on the return types of User Defined Functions. It was agreed that this should be included in the errata note for the current, [std:ADQL-20081030], version of the standard.

Futher discussion - It was also noted that the SimDAl working group would like to be able to define table value functions in std:ADQL. It was agreed to continue the discussion to find a way of adding support for table value functions in a future version of the std:ADQL standard.

Community feedback
Name date vote notes
DaveMorris 2014-07-18 +1  
       

Case-Insensitive String Comparisons

This item proposes adding functions and operators for to support case-insensitive string comparisons.

May 2014 Interop
Accepted for next version - This item was discussed by members of the working group at the May 2014 IVOA Interop meeting.

It was agreed that the following functions should be included as an optional feature in the next (minor) version of the std:ADQL standard.

  • UPPER
  • LOWER

It was agreed that the following operator should be included as an optional feature in the next (minor) version of the std:ADQL standard.

  • ILIKE

Community feedback
Name date vote notes
DaveMorris 2014-07-18 +1  
       

Set operators

This item proposes adding support for the UNION, EXCEPT and INTERSECT operators.

May 2014 Interop
Accepted for next version - This item was discussed by members of the working group at the May 2014 IVOA Interop meeting.

It was agreed that the following operators should be included in the next (minor) version of the std:ADQL standard.

  • UNION
  • EXCEPT
  • INTERSECT

It was agreed that the text describing the set operators in the std:ADQL standard should include the following caveats.

  • The set operands MUST produce the same number of columns
  • The corresponding columns in the operands MUST have the same data types
  • The corresponding columns in the operands SHOULD have the same metadata
  • The metadata for the results SHOULD be generated from the left-hand operand

Community feedback
Name date vote notes
DaveMorris 2014-07-18 -1 I agree with the proposal (+1), but we need to confirm which platforms support what operators (see below)
       

The Oracle database platform includes support for UNION and INTERSECT, but not EXCEPT. However, Oracle's MINUS opperator appears to be equivalent to EXCEPT.

If we make these operators as a required feature of std:ADQL then it means service implementatiuons based on Oracle will have to parse and translate ADQL queries.

This may not be an issue, but it will be the first time we have (knowingly) added a feature to std:ADQL that requires service implementatiuons to parse and translate ADQL queries.

-- DaveMorris - 2014-09-04

Please cotribute your knowledge to the table below to help us build a map of which platforms support which operators.

Vendor version UNION INTERSECT EXCEPT verified by
SQLServer   YES YES YES DaveMorris - 2014-09-04
Sybase        
Oracle   YES YES equivalent MINUS
PostgreSQL   YES YES YES DaveMorris - 2014-09-04
MySQL        
Derby        
HSQLBD        
SQLLite        

Revision 42014-09-04 - DaveMorris

 
META TOPICPARENT name="DaveMorris"
Notes from the TAP/ADQL splinter session on Wednesday 21 May 2014 at the IVOA Interop meeting at ESAC.

During the meeting the group reviewed a number of proposed changes to TAP and ADQL described in the TAP Implementation Notes Version 1.0.

The following section lists the recommendations agreed at the meeting for each of the changes that were reviewed.

Changed:
<
<		After each section there is a table for adding feedback.
>
>		After each section there is a table for adding feedback. Please add your vote to indicate
Deleted:
<
<		Please add your vote to indicate
 
  • +1 You agree with the decision
Changed:
<
<
  • 0 You don't mind either way
>
>
  • 0 You don't mind either way
 
  • -1 You disagree with the decision
Added:
>
>		If you vote to disagree please provide a brief one line explanation describing why (or a link to a new page if you prefer).
 
Deleted:
<
<		If you vote to disagree please provide a brief one line explanation describing why (or a link to a new page if you prefer).
 For items that need more discussion please raise them on the working group mailing list.
Changed:
<
<		Thank you for your feedback.
>
>		Thank you for your feedback. -- DaveMorris - 2014-07-18
Deleted:
<
<		-- DaveMorris - 2014-07-18
 
Changed:
<
<

1 Item xx

>
>

Example item

Added:
>
>		Some text describing the item, with a reference to the original item in the TAP Implementation Notes.
 
Changed:
<
<		Text describing the item
name vote notes
>
>
May 2014 Interop
A brief summary of the discussion at the May Interop.
Deleted:
<
<
MarcoMolinaro +1  
DaveMorris 0 Not sure
 
Added:
>
>
Community feedback
Name date vote notes
MarcoMolinaro 2014-07-18 +1  
DaveMorris 2014-07-18 +1 Yes, good idea
DaveMorris 2014-07-18 0 Ok, as long as it is optional
DaveMorris 2014-07-18 -1 It isn't the right colour, our users prefer blue background.
 
Added:
>
>

Separator Nonterminal

This item proposes two options to clarify the use of whitespace and comments in ADQL.
 
Changed:
<
<
>
>		One option for such a clarification is to amend section 2.1 of [std:ADQL] with a subsection 2.1.4, "Tokens and literals", containing text like the following (taken essentially from [std:SQL1992]).
Added:
>
>
  1. Any token may be followed by a separator. A nondelimiter token shall be followed by a delimiter token or a separator.

Since the full rules for the separator are somewhat more complex in [std:ADQL], an attractive alternative could be to omit the separator nonterminal from the grammar and to just note:

  1. Whitespace and comments can occur wherever they can occur in [std:SQL1992].

May 2014 Interop
It was agreed that this item should be included in the errata note for the current, [std:ADQL-20081030], version of the standard.

Community feedback
Name date vote notes
DaveMorris 2014-07-18 0 Accept either option

Type System

This item proposes adding new section to introduce a notion of types into section 2 of the ADQL recommendation.

See the original text for details of the proposed type mappings.

May 2014 Interop
It was agreed that this item should be discussed further, with a view to including it in the next (minor) version of the [std:ADQL] standard.

Community feedback
Name date vote notes
DaveMorris 2014-07-18 -1 In general yes, but some parts need further discussion (see below).

Transporting BLOB, CLOB, TIMESTAMP, POINT and REGION as char(*) strings should not imply the ADQL string concatenation operator are applicable. -- DaveMorris - 2014-09-04

Revision 32014-09-02 - DaveMorris

 
META TOPICPARENT name="DaveMorris"
Notes from the TAP/ADQL splinter session on Wednesday 21 May 2014 at the IVOA Interop meeting at ESAC.

During the meeting the group reviewed a number of proposed changes to TAP and ADQL described in the TAP Implementation Notes Version 1.0.

The following section lists the recommendations agreed at the meeting for each of the changes that were reviewed.

After each section there is a table for adding feedback. Please add your vote to indicate

  • +1 You agree with the decision
  • 0 You don't mind either way
  • -1 You disagree with the decision

If you vote to disagree please provide a brief one line explanation describing why (or a link to a new page if you prefer).

For items that need more discussion please raise them on the working group mailing list.

Thank you for your feedback.

Added:
>
>		-- DaveMorris - 2014-07-18
 
Changed:
<
<

0.1 Dummy Section

>
>

1 Item xx

 
Changed:
<
<		Here goes the text for the intended item due to be voted and/or discussed. Mail exchanges should also be summarized here.
>
>		Text describing the item
Added:
>
>
name vote notes
MarcoMolinaro +1  
DaveMorris 0 Not sure
 
Deleted:
<
<
agree neutral disagree
MarcoMolinaro MarcoMolinaro MarcoMolinaro
SomeoneElse   AnotherGuy
 
Deleted:
<
<
Disagreement Explanations
 
Deleted:
<
<		-- MarcoMolinaro: I disagree mainly because I'm mind splitted.

-- DaveMorris - 2014-07-18

 

Revision 22014-08-13 - MarcoMolinaro

 
META TOPICPARENT name="DaveMorris"
Notes from the TAP/ADQL splinter session on Wednesday 21 May 2014 at the IVOA Interop meeting at ESAC.

During the meeting the group reviewed a number of proposed changes to TAP and ADQL described in the TAP Implementation Notes Version 1.0.

The following section lists the recommendations agreed at the meeting for each of the changes that were reviewed.

After each section there is a table for adding feedback. Please add your vote to indicate

  • +1 You agree with the decision
  • 0 You don't mind either way
  • -1 You disagree with the decision

If you vote to disagree please provide a brief one line explanation describing why (or a link to a new page if you prefer).

For items that need more discussion please raise them on the working group mailing list.

Thank you for your feedback.

Added:
>
>

0.1 Dummy Section

Here goes the text for the intended item due to be voted and/or discussed. Mail exchanges should also be summarized here.

agree neutral disagree
MarcoMolinaro MarcoMolinaro MarcoMolinaro
SomeoneElse   AnotherGuy

Disagreement Explanations

-- MarcoMolinaro: I disagree mainly because I'm mind splitted.

  -- DaveMorris - 2014-07-18

Revision 12014-07-18 - DaveMorris

 
META TOPICPARENT name="DaveMorris"
Notes from the TAP/ADQL splinter session on Wednesday 21 May 2014 at the IVOA Interop meeting at ESAC.

During the meeting the group reviewed a number of proposed changes to TAP and ADQL described in the TAP Implementation Notes Version 1.0.

The following section lists the recommendations agreed at the meeting for each of the changes that were reviewed.

After each section there is a table for adding feedback. Please add your vote to indicate

  • +1 You agree with the decision
  • 0 You don't mind either way
  • -1 You disagree with the decision

If you vote to disagree please provide a brief one line explanation describing why (or a link to a new page if you prefer).

For items that need more discussion please raise them on the working group mailing list.

Thank you for your feedback.

-- DaveMorris - 2014-07-18

View topic | History: r11 < r10 < r9 < r8 | More topic actions...
 
This site is powered by the TWiki collaboration platform Powered by Perl This site is powered by the TWiki collaboration platformCopyright © 2008-2024 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback