The main extension of ADQL wrt SQL is addition of geometric functions. Unfortunately, these were not particularly well designed, but if you don’t expect too much, they’ll do their job.
Keep the crossmatch pattern somewhere handy (everything is in degrees):
SELECT TOP 5 rv, e_rv, p.raj2000, p.dej2000, p.pmRA, p.pmDE FROM ppmxl.main AS p JOIN rave.dr3 AS rave ON 1=CONTAINS( POINT('ICRS', p.raj2000,p.dej2000), CIRCLE('ICRS', rave.raj2000, rave.dej2000, 1.5/3600.))
In theory, you could use reference systems other than ICRS (e.g., GALACTIC, FK4) and hope the server converts the positions, but I’d avoid constructions with multiple systems – even if the server implements the stuff correctly, it’s most likely going to be slow.
When catalogs are on different epochs, you may need to account for proper motions to match faster stars. You should, however, not apply the proper motions in the primary selection. If you do that, the index cannot be used, and your query will waste a lot of CPU and disk bandwidth. Instead, decide about the maximum proper motion your objects might have (to get an idea, of the statistics, try selecting the fastest stars from ppmx.data – apart from the fact that the catalog got the fastest stars pretty wrong with two copies of some fast stars, there’s only a handful stars moving faster than four arcsecs per year).
Then multiply this with your epoch difference and make that your initial crossmatch radius. Then filter out the spurious matches with an extra where clause taking into account the proper motions. For moderate epoch differences, don’t worry about going into the tangential plane to apply proper motions and, for now, say something like
SELECT TOP 30 * FROM ppmxl.main AS m JOIN gaia.dr1 AS g ON 1=CONTAINS(POINT('ICRS', m.raj2000, m.dej2000), CIRCLE('ICRS', g.raj2000, g.dej2000, 30./3600.)) WHERE 1=CONTAINS(POINT('ICRS', m.raj2000+m.pmra*COS(RADIANS(m.dej2000))*15, m.dej2000+m.pmde*15), CIRCLE('ICRS', g.raj2000, g.dej2000, 0.5/3600.))
The 15 is because Gaia DR1 is on J2015, whereas PPMXL is on J2000. Also, be careful with the units – in many catalogs, positions and proper motions are given in different units.
Also note how the outer PM-based filter is just a WHERE-clause. Since JOIN is a combination of operators of the relational algebra, the result of a join is a relation again and thus can be treated like any other table.
Compare the radial velocities given by the rave.dr3 and arihip.main catalogs, together with the respective identifiers (hipno for arihip, name for rave). Use a positional crossmatch with, say, a couple of arcsecs.