![[Logo]](http://www.ajax.ehu.es/logoGCP.sml.gif)
To find out what tables are available for querying, see the ADQL table list.
Be sure to read Standards Compliance below.
ADQL is the Astronomical Data Query Language, an extension of a subset of the Standard Query Language SQL. Its purpose is to give you a formal language to specify what data you are interested in.
To get started using ADQL, try our ADQL course first. There are plenty of introductions SQL itself, which are perfectly useful for learning ADQL. Check your local bookstore. Online, A Gentle Introduction to SQL or chapter three of Practical PostgreSQL might be useful; for the purposes of learning ADQL, you can skip everything talking about "DDL" in general introductions.
Finally, if you're serious about using ADQL, you should at least briefly skim over the ADQL specification.
Also have a look at the TAP examples
If you give no TOP clause, the system will automatically restrict your matches to 2000 rows. This is mostly for your own protection. If you want more rows (make sure you don't throw them at your browser, i.e., select VOTable output), use SELECT TOP 100000 or something along those lines.
In particular, when doing set operations (e.g., UNION) in STC-S, no conforming of coordinate systems will be performed.
The output of ADQL geometries follows the TAP standard (simplified STC-S) rather than the ADQL standard (something similarly messy).
ADQL defines coord_sys (the first argument to the geometry functions) to be a string_value_expression; thus, you can have column references or concatenations or basically anthing there. We only allow string literals containing one of the defined coordinate systems there (these include at least the empty string, GALACTIC, UNKNOWN, ICRS, FK4, FK5, and RELOCATABLE), or NULL.
SELECT and SELECT ALL are not exactly the same thing. The latter will add an OFFSET 0 to the resulting postgresql query. Use this when the query planner messes up; see the guide star example.
Date literals can be specified as for Postgresql; you always need to use strings. So, '2000-12-31' or 'J2416642.5' are both valid date specifications. See also the historic plates example.
The ADQL (unfortunately) does not allow boolean columns. Within the data center, we do have boolean columns here and there, and it would be shame to dumb them down to integers. They show up as INTEGERs in TAP_SCHEMA, though. When you try to compare integers to them, you get an error message to the effect that an "operator does not exist: boolean = integer". To query against such columns (and have valid ADQL), use col='True' or col='False'.
Hint: You can send off your query by typing control-return from within the input text box.
Error messages for parse (and other) errors are not always as helpful as we would like them to be. Feel free to complain to us with concrete examples of where we messed up, and we'll try to improve.
![[Operator logo]](/static/img/logo_medium.png){kind=logo}